From rohc-admin@ietf.org Mon Apr 1 02:16:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17309 for ; Mon, 1 Apr 2002 02:16:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15868; Mon, 1 Apr 2002 02:01:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15836 for ; Mon, 1 Apr 2002 02:01:30 -0500 (EST) Received: from sukunx.ipv6.cwc.nus.edu.sg ([137.132.31.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10094 for ; Mon, 1 Apr 2002 02:01:25 -0500 (EST) Received: by sukunx.ipv6.cwc.nus.edu.sg (Postfix, from userid 501) id 8EC4434331; Mon, 1 Apr 2002 15:00:41 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by sukunx.ipv6.cwc.nus.edu.sg (Postfix) with ESMTP id 8D39E13265 for ; Mon, 1 Apr 2002 15:00:41 +0800 (SGT) Date: Mon, 1 Apr 2002 15:00:41 +0800 (SGT) From: Sukanta Kumar Hazra X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] Announcing a new team working on ROHC(RTP) and SigComp Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hello everyone, We at the Institute for Communications Research, Singapore (http://www.cwc.nus.edu.sg), are working on implementation of rfc3095 as well as actively starting work on SigComp. We hope that we can contribute to and gain from the ROHC working group. This mail is to inform the working group of our presence. We are also keen to collaborate and work with other teams involved in this ROHC WG. Regards, Sukanta -- ----------------------------------------------------- Sukanta Kumar Hazra R&D Engineer (Networks Division) Institute for Communications Research (Formerly the Centre for Wireless Communications) Tel : +65 68709338 Fax : +65 67795441 Email : sukanta@cwc.nus.edu.sg ----------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailman-owner@ietf.org Mon Apr 1 06:06:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17194 for ; Mon, 1 Apr 2002 06:06:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25010 for ; Mon, 1 Apr 2002 06:06:49 -0500 (EST) Date: Mon, 1 Apr 2002 06:06:49 -0500 (EST) Message-Id: <200204011106.GAA25010@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: rohc-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rohc-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rohc-web-archive@ietf.org: List Password // URL ---- -------- rohc@ietf.org umDk https://www1.ietf.org/mailman/options/rohc/rohc-web-archive@ietf.org From rohc-admin@ietf.org Mon Apr 1 12:39:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07126 for ; Mon, 1 Apr 2002 12:39:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25367; Mon, 1 Apr 2002 12:33:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25334 for ; Mon, 1 Apr 2002 12:33:47 -0500 (EST) Received: from web11708.mail.yahoo.com (web11708.mail.yahoo.com [216.136.172.74]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06871 for ; Mon, 1 Apr 2002 12:33:42 -0500 (EST) Message-ID: <20020401173342.75119.qmail@web11708.mail.yahoo.com> Received: from [143.209.230.171] by web11708.mail.yahoo.com via HTTP; Mon, 01 Apr 2002 09:33:42 PST Date: Mon, 1 Apr 2002 09:33:42 -0800 (PST) From: Behcet Sarikaya To: sarikayab@yahoo.com Cc: pilc@grc.nasa.gov, rohc@ietf.org In-Reply-To: <00bb01c1c92d$ff481570$686015ac@docomocarl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [rohc] Re: L2 Triggers Bar-BOF Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Dear all, I am pleased to announce the mailing list to discuss IP Paging at ip-paging@alcatel.com To subscribe send an email to the mailing list administrator at: behcet.sarikaya@alcatel.com We expect to post more info on Tuesday after Easter. --behcet PS. Previous posts failed, trying this one __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Mon Apr 1 18:06:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18519 for ; Mon, 1 Apr 2002 18:06:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18041; Mon, 1 Apr 2002 17:53:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18010 for ; Mon, 1 Apr 2002 17:53:07 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18341 for ; Mon, 1 Apr 2002 17:53:02 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g31MqYQ90670; Tue, 2 Apr 2002 00:52:34 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.32] ([192.168.102.32]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA04043; Tue, 2 Apr 2002 00:52:26 +0200 Date: Tue, 02 Apr 2002 00:55:29 +0200 From: Juergen Quittek To: Behcet Sarikaya cc: pilc@grc.nasa.gov, rohc@ietf.org Subject: Re: [rohc] Re: L2 Triggers Bar-BOF Message-ID: <71239887.1017708929@[192.168.102.32]> In-Reply-To: <20020401173342.75119.qmail@web11708.mail.yahoo.com> References: <20020401173342.75119.qmail@web11708.mail.yahoo.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit Behcet, --On 01 April 2002 09:33 -0800 sarikayab@yahoo.com wrote: > Dear all, > I am pleased to announce the mailing list to discuss > IP Paging at > ip-paging@alcatel.com How is this new list related to the mailing list that spun off the IETF seamoby mailing list (dmha@ccrle.nec.de)? As far as I understood, the goal of dmha@ccrle.nec.de the continuation of he paging work at the seamoby wg (see cited announcement below). What are the goals of your list? Is this a parallel list? Do we have to cross post? Are you covering more specific or more general issues? Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de % From: Marco Liebsch % To: Seamoby % Subject: [Seamoby] continuation on DMHA protocol specification % Date-Sent: 26 March 2002 12:12 +0100 % % Hi IP pagers, % % according to the notification during Seamoby WG session at IETF#53, DMHA % specification will be taken out of Seamoby WG's activities. Since there % has already been done very good work in this area, I propose to not % throw away what's already there. So, let us continue working on % technical issues of DMHA specification where respective Seamoby % activities terminated. As a first step we set up a separate mailing list % for DMHA protocol specification purposes. Everybody who is interested is % invited to participate. % % Simply subscribe to the DMHA mailing list: % send a 'subscribe dmha' to 'majordomo@ccrle.nec.de' and follow % instructions sent to you by majordomo. % The address of the list is 'dmha@ccrle.nec.de'. % % I am looking forward to have good technical continuation of work on DMHA % protocol development. > > > To subscribe send an email to the mailing list > administrator at: > behcet.sarikaya@alcatel.com > > We expect to post more info on Tuesday after Easter. > > > --behcet > > PS. Previous posts failed, trying this one > > __________________________________________________ > Do You Yahoo!? > Yahoo! Greetings - send holiday greetings for Easter, Passover > http://greetings.yahoo.com/ > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 2 07:56:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13599 for ; Tue, 2 Apr 2002 07:56:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09033; Tue, 2 Apr 2002 07:44:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09002 for ; Tue, 2 Apr 2002 07:44:07 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13400 for ; Tue, 2 Apr 2002 07:44:05 -0500 (EST) Received: from viola.eth.ericsson.se (viola.eth.ericsson.se [164.48.159.55]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g32Ci5s7000294 for ; Tue, 2 Apr 2002 14:44:05 +0200 (MEST) Received: from eth.ericsson.se (a09056.eth.ericsson.se [164.48.159.56]) by viola.eth.ericsson.se (Netscape Messaging Server 3.6) with ESMTP id AAA510D; Tue, 2 Apr 2002 14:44:02 +0200 Message-ID: <3CA9A764.3080908@eth.ericsson.se> Date: Tue, 02 Apr 2002 14:43:16 +0200 From: Peter Kremer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: rohc@ietf.org CC: zhigang.c.liu@nokia.com Subject: Re: [rohc] additions to ROHC Implementer's Guide References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit Hi, See my commetns inline. > Packet updating properties in R-mode > ------------------------------------- > > The updating properties of packets in R-mode can be crystallized as > follows: > > - An update packet is a packet that carries CRC. It updates both > compressor context and decompressor context. I think it's already clear. See section 5.5.1.2.: "... only a packet carrying a 7- or 8-bit CRC can update the decompression context and be used as a reference for subsequent decompression." Section 5.5.2.2.: "... an updating packet (i.e., a packet carrying a 7- or 8-bit CRC) is correctly decompressed..." > - An update packet in R-mode updates ALL header fields. > If the packet carry information about a field X, X is updated > using that piece of information. For a field Y that is not > explicitly mentioned, Y is updated by the established function > from RTP SN to Y: Y = f_y(SN) (see ROHC section 3.4 and 5.5.1.2). It doesn't relate to R-mode only and I think section 4.7. is about the same problem. > - A compressor expects the decompressor to follow above rules > and use the updated fields as references to decompress subsequent > packets. This allows the decompressor context follows the compressor > context closely and thus improve efficiency (i.e. less bits are > needed to convey a change) > > - Specifically, above applies to R-0-CRC. I'm afraid I don't understand it. What's the problem if a decompressor follows these rules? > [zliu: section 4.7 in current draft is not accurate about R-0] If you mean the "implicit update" problem then you're right. This section should be more general. > R-1* packets > ------------ > > R-1* packets do not update either compressor context or decompressor > context (see ROHC section 5.2.7). I.e., they are not "remembered" by > either compressor or decompressor. Consequently, an R-1* can be sent > by a compressor at any state except IR state. Specifically, a compressor > may send R-1* packets in SO state and that (alone) does not mean the > compressor must transit to FO state. In R-mode upward transition is based on the received acknowledgements. Since these packets don't update the context it's obvious that the decompressor doesn't send ACKs (5.5.2.2.) and the compressor doesn't transit to an upward state. Regarding this logic, I fully agree with you, but it's already present in the RFC. I don't see any reason to mention it again in the draft. > Below lists design goals of R-1*, but an implementer may find other > usage scenarios: > > a) to handle a transient change in packet stream (i.e. a field > changes its value only in current packet but then reverts back > to its normal pattern). E.g. suddenly appeared extension header. > > b) to handle the case where a header field always changes without > fixed pattern, but not randomly either. E.g. RTP timestamp for video > codecs. > > c) to reduce the feedback traffic in an update procedure which > is carried over a channel with long RTT (see ROHC section 5.5.1.2) > > d) above also reduces the memory consumption (e.g. sliding window size) > on compressor and decompressor side. I think c) applies to R-mode only, the others are true for the other two modes as well. Let's think about it and get back to your list after the next interop test (when I'll update the draft). Best regards, -- Peter Kremer, MBA Tel: +36-1-437-7033 Ericsson Hungary Ltd. Fax: +36-1-437-7767 Conformance Center ETH/RL/S Mobile: +36-30-311-2118 http://conformancelab.ericsson.se E-mail: Peter.Kremer@eth.ericsson.se _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 2 08:57:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15204 for ; Tue, 2 Apr 2002 08:57:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12219; Tue, 2 Apr 2002 08:46:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12188 for ; Tue, 2 Apr 2002 08:46:55 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14830 for ; Tue, 2 Apr 2002 08:46:52 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g32Dkqs7004967 for ; Tue, 2 Apr 2002 15:46:52 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 15:44:45 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 15:34:32 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'rohc@ietf.org'" Date: Tue, 2 Apr 2002 15:42:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] sigcomp issue lejo-4 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org > lejo-4) In terminology and section 6.1, second paragraph, dynamic > compression > is mentioned as an important mechanism for improved > compression > efficiency, but not at all explained how to > implement. We all know > why, but for a reader this is strange. Should we > clearly refer to > the document that explains how to implement this and > other useful > enhancements? > > [[ > This is a document dependendy question. > Discuss. > ]] I think we should at least write something like "[further documents will be (are) available]" in SigComp-06. BR /Hans H _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 2 09:54:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17698 for ; Tue, 2 Apr 2002 09:54:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16155; Tue, 2 Apr 2002 09:44:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16118 for ; Tue, 2 Apr 2002 09:44:52 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17348 for ; Tue, 2 Apr 2002 09:44:50 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g32Ein3G018877 for ; Tue, 2 Apr 2002 16:44:49 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 16:42:35 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 16:44:29 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'rohc@ietf.org'" Date: Tue, 2 Apr 2002 16:43:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] sigcomp issue lejo-10 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org > lejo-10) Extended operations: To support e.g. explicit acks is an > implementation issue. However, as SigComp is now > defined, this > is about having it implemented at both "sides" to get the > functionality. What I mean is that to use dynamic compression > between compressor1 and decompressor2, compressor2 > must provide > acks for decompressor2 states. Is this a nice > solution? Would it > not be possible to define SigComp so that compressor1 could > implement this by using the right UDVM instructions to force > "state acks" for saved state from decompressor2? As > it is now, both > sides must explicitly implement this to get any > benefits, and that > is not a nice way of having an implementation option. Well, we had something that could have been used for this in SigComp-04, i.e. Requested and Returned information. But, I'm not sure if that had worked without at least a modification to the END-MESSAGE instruction. However, I've have a vague memory of some discussion in Minneapolis that there may be some security issues with that approach, is there anyone that recalls this? Anyway, the approach in SigComp-05 and Extended-02, i.e. endpoint B decides whether to acknowledge state(s) to endpoint A, seems to work with the current set of UDVM instructions, and I believe it is easier for endpoint B to keep track of what states it has acknowledged, this knowledge may be useful when SigComp is applied in an environment were packet losses may occur. Perhaps it is not the "nicest" solution, but as "state-acks" from endpoint B would gain endpoint B as it would gain endpoint A, (often SigComp would be applied in a two-way communication, consider e.g. SIP), then I think both endpoints would be glad to get the message exchange over with as fast as possible. So, I think it is good to keep the approach we have in SigComp-05 and extended-02. BR /Hans H _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 2 12:59:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26193 for ; Tue, 2 Apr 2002 12:59:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01710; Tue, 2 Apr 2002 12:50:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01669 for ; Tue, 2 Apr 2002 12:50:31 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25755 for ; Tue, 2 Apr 2002 12:50:29 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g32Hoi507870 for ; Tue, 2 Apr 2002 20:50:44 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 20:50:28 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 20:50:28 +0300 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:50:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] additions to ROHC Implementer's Guide Date: Tue, 2 Apr 2002 11:50:19 -0600 Message-ID: Thread-Topic: [rohc] additions to ROHC Implementer's Guide Thread-Index: AcHaRBYvFLVwiaQ7QdSqAjm2sD0hYAAITA3A To: , X-OriginalArrivalTime: 02 Apr 2002 17:50:19.0860 (UTC) FILETIME=[DB00B940:01C1DA6E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA01673 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit Peter, > > Packet updating properties in R-mode > > ------------------------------------- > > > > The updating properties of packets in R-mode can be crystallized as > > follows: > > > > - An update packet is a packet that carries CRC. It updates both > > compressor context and decompressor context. > > I think it's already clear. It is to clarify that update packets update compressor context. > > - An update packet in R-mode updates ALL header fields. > > If the packet carry information about a field X, X is updated > > using that piece of information. For a field Y that is not > > explicitly mentioned, Y is updated by the established function > > from RTP SN to Y: Y = f_y(SN) (see ROHC section 3.4 and 5.5.1.2). > > It doesn't relate to R-mode only and I think section 4.7. is > about the same problem. Note the "ALL" in above statement. Section 4.7 talks only about TS and IP-ID. That is incorrect at least from R-mode perspective. In R-mode, you simply update ALL fields. There is no difference between TS and IP-ID or any other header fields. (I actually raised this issue during the "authors 48 hours" before publishing of the RFC, which trigered the addition of "implicit" in updating properties in section 5.7. But that doesn't seem to be clear enough.) > > - A compressor expects the decompressor to follow above rules > > and use the updated fields as references to decompress subsequent > > packets. This allows the decompressor context follows the compressor > > context closely and thus improve efficiency (i.e. less bits are > > needed to convey a change) > > > > - Specifically, above applies to R-0-CRC. > > > I'm afraid I don't understand it. What's the problem if a > decompressor follows these rules? I guess you meant to say what if "a decompressor does not follow these rules"? The answer is that when a non-SN field Y changes irregularly, the compressor needs to calculate how many bits need to be sent. For that calculation, the compressor has to know whether Y is updated on the decompressor side by previous R-0-CRC packets or not. > > R-1* packets > > ------------ > > > > R-1* packets do not update either compressor context or decompressor > > context (see ROHC section 5.2.7). I.e., they are not "remembered" by > > either compressor or decompressor. Consequently, an R-1* can be sent > > by a compressor at any state except IR state. Specifically, a compressor > > may send R-1* packets in SO state and that (alone) does not mean the > > compressor must transit to FO state. > > In R-mode upward transition is based on the received acknowledgements. > Since these packets don't update the context it's obvious that the > decompressor doesn't send ACKs (5.5.2.2.) and the compressor doesn't > transit to an upward state. Sorry, I don't follow you. What you said above is not what I'm trying to clarify here. The example I give is actually about downward state transition, not upward. My text here is to clarify that R-1* can be sent in *any* state except IR. That is not clear in RFC 3095 and has triggered many questions in the mailing list. Some people think R-1* can only be sent in FO state, which is untrue. > Regarding this logic, I fully agree with you, but it's already present > in the RFC. I don't see any reason to mention it again in the draft. It is not (see above). > > Below lists design goals of R-1*, but an implementer may find other > > usage scenarios: > > > > a) to handle a transient change in packet stream (i.e. a field > > changes its value only in current packet but then reverts back > > to its normal pattern). E.g. suddenly appeared extension header. > > > > b) to handle the case where a header field always changes without > > fixed pattern, but not randomly either. E.g. RTP timestamp for video > > codecs. > > > > c) to reduce the feedback traffic in an update procedure which > > is carried over a channel with long RTT (see ROHC section 5.5.1.2) > > > > d) above also reduces the memory consumption (e.g. sliding window size) > > on compressor and decompressor side. > > I think c) applies to R-mode only, True. > the others are true for the other two modes as well. What do you mean? The text is about R-1*, which is used in R-mode only. Again, R-1* was designed with a clear goal not to update *any* context, not RTP TS, not IP-ID, not even RTP SN. It is different from UO-1*. So, R-1* deserves some clarifications which was not included in RFC 3095 due to its size. > Let's think about it and get back to your list > after the next interop test (when I'll update the draft). OK. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 2 18:51:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08704 for ; Tue, 2 Apr 2002 18:51:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24703; Tue, 2 Apr 2002 18:33:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24667 for ; Tue, 2 Apr 2002 18:33:09 -0500 (EST) Received: from odin.tuclab ([208.1.25.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08002 for ; Tue, 2 Apr 2002 18:33:06 -0500 (EST) Received: from effnet.com (apollo.tuclab [172.16.11.11]) by odin.tuclab (8.11.2/8.11.2) with ESMTP id g32NViL21829; Tue, 2 Apr 2002 16:31:44 -0700 Message-ID: <3CAA3F5F.1090506@effnet.com> Date: Tue, 02 Apr 2002 16:31:43 -0700 From: Kausik B Sinnaswamy Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: rohc@ietf.org, kausik@effnet.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] Arctic RoHC Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit Dear RoHCers I am one of the implementors of RoHC at Effnet Inc. We would like to inter operate the following at the bake off in Lulea in April: a. Profile 1: 1. CSRC-List compression. 2. IPv6 3. Outer header behavior 4. Extension header list compression. b. Profiles: 0, 2 and 3. c. Robustness testing 1. Use of LOSS_OPTION. 2. Context damage adapting by the compressor. d. RoHC over PPP with Negotiation. Thanks -Kausik _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 2 19:19:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09391 for ; Tue, 2 Apr 2002 19:19:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26527; Tue, 2 Apr 2002 19:05:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26492 for ; Tue, 2 Apr 2002 19:05:03 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08963 for ; Tue, 2 Apr 2002 19:05:03 -0500 (EST) From: Narendra.Chaparala@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3305Ms05969 for ; Tue, 2 Apr 2002 18:05:22 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 2 Apr 2002 18:05:02 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 18:04:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 2 Apr 2002 18:04:39 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD6E86CF@daebe008.NOE.Nokia.com> Thread-Topic: sigcomp -05: Multiload instruction Thread-Index: AcHaoyayiOoRiFtjRSOdUuL68yU8XA== To: X-OriginalArrivalTime: 03 Apr 2002 00:04:39.0418 (UTC) FILETIME=[25F14DA0:01C1DAA3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA26493 Subject: [rohc] sigcomp -05: Multiload instruction Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit Does the Multiload instruction execution similar to COPY instruction when byte_copy_right is reached while loading the values? I mean does the next load starts at byte_copy_left or the decompressor needs to fail as per section 7.3 " if a byte is read from an address beyond the overall memory size then decompression failure occurs" Thanks, Narendra _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 00:25:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16667 for ; Wed, 3 Apr 2002 00:25:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12813; Wed, 3 Apr 2002 00:07:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12783 for ; Wed, 3 Apr 2002 00:06:59 -0500 (EST) Received: from sukunx.ipv6.cwc.nus.edu.sg ([137.132.31.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16352 for ; Wed, 3 Apr 2002 00:06:55 -0500 (EST) Received: by sukunx.ipv6.cwc.nus.edu.sg (Postfix, from userid 501) id 439DF1DF1E; Wed, 3 Apr 2002 13:06:16 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by sukunx.ipv6.cwc.nus.edu.sg (Postfix) with ESMTP id 3F3E2CF7B for ; Wed, 3 Apr 2002 13:06:16 +0800 (SGT) Date: Wed, 3 Apr 2002 13:06:16 +0800 (SGT) From: Sukanta Kumar Hazra X-X-Sender: To: In-Reply-To: <3CA9A764.3080908@eth.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] ROHC Implementation : Determining an RTP packet Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi! everyone, A small question about ROHC implementation. Since RFC 3096 in section 2.1, states 2. Ubiquity: Must not require modifications to existing IP (v4 or v6), UDP, or RTP implementations. And RTP does not have a protocol number. Therefore how does a ROHC implementation determine if the payload carried by UDP is RTP packet or not? Regards, Sukanta _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 02:08:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26189 for ; Wed, 3 Apr 2002 02:08:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28401; Wed, 3 Apr 2002 01:57:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28370 for ; Wed, 3 Apr 2002 01:57:29 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17859 for ; Wed, 3 Apr 2002 01:57:25 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g336uBs7006251 for ; Wed, 3 Apr 2002 08:56:11 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Apr 03 08:54:14 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 08:56:10 +0200 Message-ID: From: "Peter Kremer (ETH)" To: "'Sukanta Kumar Hazra'" , rohc@ietf.org Subject: RE: [rohc] ROHC Implementation : Determining an RTP packet Date: Wed, 3 Apr 2002 08:54:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi, > And RTP does not have a protocol number. Therefore how does a ROHC > implementation determine if the payload carried by UDP is RTP > packet or > not? It's based on the profile number. If profile == 1 then the UDP payload contains an RTP packet. If profile == 2 then the UDP payload is something else. /Peter _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 03:56:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27470 for ; Wed, 3 Apr 2002 03:56:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04949; Wed, 3 Apr 2002 03:49:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04915 for ; Wed, 3 Apr 2002 03:49:26 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27415 for ; Wed, 3 Apr 2002 03:49:23 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g338nQs7010794 for ; Wed, 3 Apr 2002 10:49:26 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 03 10:49:19 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 10:49:18 +0200 Message-ID: From: "Peter Kremer (ETH)" To: "Rohc (E-mail)" Date: Wed, 3 Apr 2002 10:45:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Subject: [rohc] Arctic ROHC - deadline Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi, I'd like to remind you that the deadline expires today for Arctic ROHC. If you are interested and haven't registered yet, please do it ASAP. Further information can be found at: http://standards.ericsson.net/rohc/ -- Peter Kremer, MBA Tel: +36-1-437-7033 Ericsson Hungary Ltd. Fax: +36-1-437-7767 Conformance Center ETH/RL/S Mobile: +36-30-311-2118 http://conformancelab.ericsson.se E-mail: Peter.Kremer@eth.ericsson.se _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 04:09:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27688 for ; Wed, 3 Apr 2002 04:09:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05192; Wed, 3 Apr 2002 03:57:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05160 for ; Wed, 3 Apr 2002 03:57:46 -0500 (EST) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27505 for ; Wed, 3 Apr 2002 03:57:43 -0500 (EST) Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id g338vKZ17728; Wed, 3 Apr 2002 10:57:25 +0200 (MEST) From: "Dr. Carsten Bormann" To: "Sukanta Kumar Hazra" , Subject: RE: [rohc] ROHC Implementation : Determining an RTP packet Date: Wed, 3 Apr 2002 10:57:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit > And RTP does not have a protocol number. Therefore how does a ROHC > implementation determine if the payload carried by UDP is RTP packet or > not? Essentially, it has to guess. There is no way to find out reliably. (There was a long discussion in the 1990s if RTP packets could be made self-describing, e.g., by giving them a separate IP protocol number. That did not happen, for a number of good reasons.) Note that there is no problem if the implementation guesses wrong: RTP compression is transparent, so non-RTP bits won't be damaged. (This was one of the strong reasons to require bit-wise transparency.) Some heuristics that might work: -- UDP payloads start with the bits 10xxxxxx -- UDP payloads are at least 12 bytes (You can't compress packet flows with RTP ROHC that don't have these properties.) Also, set X and P bits are probably a good indication that this isn't an RTP packet (although that might change with new uses of RTP). After you have seen a few packets: -- The sequence number mostly increases by 1 -- The timestamp number increases in a regular way relative to the sequence number -- SSRC and PT are more or less constant -- CC is varying slowly (These are all the conditions that make RTP ROHC *efficient* -- again, it "works" even in the absence of these conditions.) If the implementation was wrong in guessing RTP, it can use the mechanism defined in item 2 of 5.11.1 to save re-sending the context when switching to the UDP profile. So it is not too expensive to be aggressive in guessing RTP. Peter: Would this make good material for the implementers guide? Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 05:50:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29019 for ; Wed, 3 Apr 2002 05:50:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11328; Wed, 3 Apr 2002 05:45:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11295 for ; Wed, 3 Apr 2002 05:45:39 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28902 for ; Wed, 3 Apr 2002 05:45:34 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33Aj8859300; Wed, 3 Apr 2002 12:45:08 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA21379; Wed, 3 Apr 2002 12:44:56 +0200 Date: Wed, 03 Apr 2002 12:48:08 +0200 From: Juergen Quittek To: Sukanta Kumar Hazra , rohc@ietf.org Subject: Re: [rohc] Announcing a new team working on ROHC(RTP) and SigComp Message-ID: <10471777.1017838088@[192.168.102.164]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit Hi Sukanta, It is great to have another implementation! I am sure your contribution will be appreciated very much. Please excuse my obtrusiveness: Do you also plan to implement a MIB for monitoring your implementation? Best reagrds, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 01 April 2002 15:00 +0800 Sukanta Kumar Hazra wrote: > Hello everyone, > > We at the Institute for Communications Research, Singapore > (http://www.cwc.nus.edu.sg), are working on implementation of rfc3095 as > well as actively starting work on SigComp. We hope that we can contribute > to and gain from the ROHC working group. This mail is to inform the > working group of our presence. > > We are also keen to collaborate and work with other teams involved in this > ROHC WG. > > > Regards, > Sukanta > > > -- > ----------------------------------------------------- > Sukanta Kumar Hazra > R&D Engineer (Networks Division) > Institute for Communications Research > (Formerly the Centre for Wireless Communications) > Tel : +65 68709338 > Fax : +65 67795441 > Email : sukanta@cwc.nus.edu.sg > ----------------------------------------------------- > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 06:00:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29178 for ; Wed, 3 Apr 2002 06:00:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12108; Wed, 3 Apr 2002 05:52:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12072 for ; Wed, 3 Apr 2002 05:52:46 -0500 (EST) Received: from sukunx.ipv6.cwc.nus.edu.sg ([137.132.31.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29041 for ; Wed, 3 Apr 2002 05:52:40 -0500 (EST) Received: by sukunx.ipv6.cwc.nus.edu.sg (Postfix, from userid 501) id C510D38DD4; Wed, 3 Apr 2002 18:52:06 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by sukunx.ipv6.cwc.nus.edu.sg (Postfix) with ESMTP id C0CDC19104; Wed, 3 Apr 2002 18:52:06 +0800 (SGT) Date: Wed, 3 Apr 2002 18:52:06 +0800 (SGT) From: Sukanta Kumar Hazra X-X-Sender: To: Juergen Quittek Cc: Subject: Re: [rohc] Announcing a new team working on ROHC(RTP) and SigComp In-Reply-To: <10471777.1017838088@[192.168.102.164]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi! No plans yet for an MIB yet. Our implementation is pretty much a research tool (ICR is a research organization). However we will surely keep the MIB in mind, and if we find some expertise here in that area, then we can go ahead with that. Regards, Sukanta -- ----------------------------------------------------- Sukanta Kumar Hazra R&D Engineer (Networks Division) Institute for Communications Research (Formerly the Centre for Wireless Communications) Tel : +65 68709338 Fax : +65 67795441 Email : sukanta@cwc.nus.edu.sg ----------------------------------------------------- On Wed, 3 Apr 2002, Juergen Quittek wrote: > Hi Sukanta, > > It is great to have another implementation! I am sure your > contribution will be appreciated very much. > > Please excuse my obtrusiveness: > Do you also plan to implement a MIB for monitoring your > implementation? > > Best reagrds, > > Juergen > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 06:26:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29598 for ; Wed, 3 Apr 2002 06:26:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14118; Wed, 3 Apr 2002 06:20:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14089 for ; Wed, 3 Apr 2002 06:20:56 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29504 for ; Wed, 3 Apr 2002 06:20:51 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:17:43 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFA8@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Hans Hannu (EPL)'" , "'rohc@ietf.org'" Subject: RE: [rohc] sigcomp issue lejo-10 Date: Wed, 3 Apr 2002 12:17:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" > > lejo-10) Extended operations: To support e.g. explicit acks is an > > implementation issue. However, as SigComp is now defined, this > > is about having it implemented at both "sides" to get the > > functionality. What I mean is that to use dynamic compression > > between compressor1 and decompressor2, compressor2 must provide > > acks for decompressor2 states. Is this a nice solution? Would it > > not be possible to define SigComp so that compressor1 could > > implement this by using the right UDVM instructions to force > > "state acks" for saved state from decompressor2? As it is now, both > > sides must explicitly implement this to get any benefits, and that > > is not a nice way of having an implementation option. > > Well, we had something that could have been used for this in > SigComp-04, i.e. Requested and Returned information. But, I'm > not sure if that had worked without at least a modification > to the END-MESSAGE instruction. > However, I've have a vague memory of some discussion in > Minneapolis that there may be some security issues with that > approach, is there anyone that recalls this? Hi Hans, I believe that this discussion was with me. The security issue that I raised was just that a compressor could overload the reverse channel by making an excessively large number of feedback requests; however this can easily be solved by only allowing one feedback request per message and setting an upper bound for the size of the feedback data. > Anyway, > the approach in SigComp-05 and Extended-02, i.e. endpoint B > decides whether to acknowledge state(s) to endpoint A, seems > to work with the current set of UDVM instructions, and I > believe it is easier for endpoint B to keep track of what > states it has acknowledged, this knowledge may be useful when > SigComp is applied in an environment were packet losses may occur. The weakness of the current solution is that the choice of whether to send explicit acks to Endpoint A or not is made by Endpoint B. However, we have an alternative solution for acknowledgements (namely implicit acks); the decision on whether to these or not is made by Endpoint A. Since there is no way for Endpoint B to work out what Endpoint A is doing, we might end up with both ack schemes running over the same channel. Even worse, we might end up with no ack scheme at all because each endpoint expects the other endpoint to handle the acknowledgements. > Perhaps it is not the "nicest" solution, but as "state-acks" > from endpoint B would gain endpoint B as it would gain > endpoint A, (often SigComp would be applied in a two-way > communication, consider e.g. SIP), then I think both > endpoints would be glad to get the message exchange over with > as fast as possible. If Endpoint A is using an implicit ack scheme, then the explicit acks sent by Endpoint B are wasted. The cost of explicit acks is quite high (currently 10 - 20 bytes per packet), which is a lot of bandwidth to throw away for no gain. > So, I think it is good to keep the approach we have in > SigComp-05 and extended-02. I believe that SigComp-06 should have the Requested and Returned feedback of SigCompo-04. This will need a bigger update to the drafts, but I think that it is worthwhile because it will be a significant improvement over the current solution. Regards, Richard --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 06:32:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29718 for ; Wed, 3 Apr 2002 06:32:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14352; Wed, 3 Apr 2002 06:26:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14323 for ; Wed, 3 Apr 2002 06:26:40 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29614 for ; Wed, 3 Apr 2002 06:26:37 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:25:29 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFA9@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Narendra.Chaparala@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] sigcomp -05: Multiload instruction Date: Wed, 3 Apr 2002 12:25:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, The MULTILOAD instruction ignores byte_copy_left and byte_copy_right. In general they are only used when explicitly indicated in the draft; instructions ignore them unless told to do otherwise. Regards, Richard > -----Original Message----- > From: Narendra.Chaparala@nokia.com > [mailto:Narendra.Chaparala@nokia.com] > Sent: Wednesday, April 03, 2002 1:05 AM > To: rohc@ietf.org > Subject: [rohc] sigcomp -05: Multiload instruction > > > Does the Multiload instruction execution similar to COPY > instruction when byte_copy_right is reached while loading the > values? I mean does the next load starts at byte_copy_left > or the decompressor needs to fail as per section 7.3 " if a > byte is read from an address beyond the overall memory size > then decompression failure occurs" > > Thanks, > Narendra > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 07:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00476 for ; Wed, 3 Apr 2002 07:19:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16959; Wed, 3 Apr 2002 07:05:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16927 for ; Wed, 3 Apr 2002 07:05:40 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00242 for ; Wed, 3 Apr 2002 07:05:36 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g33C5bs7021439 for ; Wed, 3 Apr 2002 14:05:37 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 03 14:05:23 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 14:07:05 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'Price, Richard'" , "'rohc@ietf.org'" Subject: RE: [rohc] sigcomp issue lejo-10 Date: Wed, 3 Apr 2002 14:05:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi Richard, > Even worse, we might end up with no ack scheme at all > because each endpoint expects the other endpoint to handle the > acknowledgements. Well, an endpoint could keep track of what states that are being requested/accessed by the remote endpoint so I do not think that will happen, but it would be a matter of implementation. Anyway, would the announcement information look something like below in SigComp-06 then? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDVM_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SigComp parameters | : : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : id_value_1 : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : id_value_n : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested data length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Requested data : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Returned data length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Returned data : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : reserved : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BR /Hans H _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 07:39:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01010 for ; Wed, 3 Apr 2002 07:39:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19367; Wed, 3 Apr 2002 07:33:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19334 for ; Wed, 3 Apr 2002 07:33:47 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00815 for ; Wed, 3 Apr 2002 07:33:43 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 13:32:32 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFAA@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Hans Hannu (EPL)'" , "'rohc@ietf.org'" Subject: RE: [rohc] sigcomp issue lejo-10 Date: Wed, 3 Apr 2002 13:32:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Hans, The receiving endpoint could certainly track the states that are being accessed and attempt to guess whether explicit acks are needed or not. However this might take quite a few RTTs, and the endpoint would also have to download some new bytecode on the fly which is quite costly. I believe that the format of the requested feedback should be as follows: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 0 | requested_feedback | | 1 | requested_feedback_length | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | : requested_feedback : | | +---+---+---+---+---+---+---+---+ The returned feedback format should be identical. The reason for the above encoding is that the requested feedback does not have to be a state identifier; any message identifier will suffice as long as the sender does not reuse a MID before it has been acknowledged. The above encoding is very efficient for the case that at most 128 distinct MIDs are required (which is typically more than enough). The SigComp parameters (including the state identifiers for the state created by the sender) should be announced similarly to SigComp-05. Regards, Richard > -----Original Message----- > From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > Sent: Wednesday, April 03, 2002 1:05 PM > To: Price, Richard; 'rohc@ietf.org' > Subject: RE: [rohc] sigcomp issue lejo-10 > > > Hi Richard, > > > Even worse, we might end up with no ack scheme at all > > because each endpoint expects the other endpoint to handle the > > acknowledgements. > > Well, an endpoint could keep track of what states that are > being requested/accessed by the remote endpoint so I do not > think that will happen, but it would be a matter of implementation. > > Anyway, would the announcement information look something > like below in SigComp-06 then? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | UDVM_version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SigComp parameters | > : : > : : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | id_length 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : id_value_1 : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | id_length n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : id_value_n : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Requested data length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : Requested data : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Returned data length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : Returned data : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : reserved : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > BR > /Hans H > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 10:36:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06475 for ; Wed, 3 Apr 2002 10:36:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00071; Wed, 3 Apr 2002 10:07:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00038 for ; Wed, 3 Apr 2002 10:07:01 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05292 for ; Wed, 3 Apr 2002 10:06:58 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g33F6ws7029594 for ; Wed, 3 Apr 2002 17:06:58 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 03 17:06:47 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 16:56:33 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'rohc@ietf.org'" Date: Wed, 3 Apr 2002 16:54:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] maximum_expansion_size Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi, Just a minor comment, If compression is applied on encrypted messages the result might instead be an expansion of the message (depends of course on the algorithm). Anyway, if this parameter is set to anything else than zero it might result in no output from SigComp. I just wonder if we should put a note along with description of the maximum_expansion_size regarding this: "Note: If encryption is applied before compression, the resulting message after compression might instead be expanded. This needs to be considered when setting the maximum_expansion_size" Perhaps this should go into the UDVM user guide instead? Or perhaps this is so uncommon that we do not need to mention it all? BR /Hans H _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 11:18:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07880 for ; Wed, 3 Apr 2002 11:18:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05707; Wed, 3 Apr 2002 11:10:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05666 for ; Wed, 3 Apr 2002 11:09:58 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07617 for ; Wed, 3 Apr 2002 11:09:54 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g33GAC503191 for ; Wed, 3 Apr 2002 19:10:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 19:09:57 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 19:09:56 +0300 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 10:09:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] sigcomp issue lejo-10 Date: Wed, 3 Apr 2002 10:09:36 -0600 Message-ID: Thread-Topic: [rohc] sigcomp issue lejo-10 Thread-Index: AcHbAgXGv5eZs4iVTvK0wDJH66eTKgAJwWXA To: , , X-OriginalArrivalTime: 03 Apr 2002 16:09:37.0162 (UTC) FILETIME=[F3AFEEA0:01C1DB29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA05667 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit > I believe that this discussion was with me. The security issue > that I raised was just that a compressor could overload the > reverse channel by making an excessively large number of feedback > requests; however this can easily be solved by only allowing one > feedback request per message and setting an upper bound for the > size of the feedback data. ... or we could count the feedback triggered by compressor-1 as part of its state budget. Anyway, a feedback request needs to pass the same security check as a state creation request. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 3 19:32:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19979 for ; Wed, 3 Apr 2002 19:32:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08526; Wed, 3 Apr 2002 19:21:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08493 for ; Wed, 3 Apr 2002 19:21:38 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19768 for ; Wed, 3 Apr 2002 19:21:32 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g340Ln524092 for ; Thu, 4 Apr 2002 03:21:49 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 03:21:34 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 03:21:34 +0300 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 18:21:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] sigcomp issue lejo-10 Date: Wed, 3 Apr 2002 18:21:31 -0600 Message-ID: Thread-Topic: [rohc] sigcomp issue lejo-10 Thread-Index: AcHbEGAfPOJTbUsyRviAwFVcU4PaywAVKq/Q To: , , X-OriginalArrivalTime: 04 Apr 2002 00:21:31.0622 (UTC) FILETIME=[ABAD2060:01C1DB6E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA08494 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit Hi, Why do we need to standardize the format for feedback *data* at all? It looks to me that we only need to standardize some *encapsulation* format for feedback (see Hans' email http://www.cdt.luth.se/robhc/msg03674.html). Then, the following procedure should work (basically, let the compressor controls the feedback format.) (Some notation: A is one endpoint and B is the other. compressor-A1 means compressor 1 of endpoint A) 1) compressor-A1 sends to SigComp B the UDVM code that can generate feedback data when parsing a compressed message. 2) SigComp B: the UDVM generates feedback similarly to the creation of state. 3) if the decompressed message that triggered the feedback passes security check, the feedback is passed to compressor-B1 (that talks to SigComp A). Note the role of endpoint ID here. 4) Compressor-B1 piggybacks the feedback with a compressed message sent to endpoint A. 5) decompressor-A pass the feedback to compressor-A1. 6) compressor-A1 parse the feedback. It knows the format. Note in 4), a standalone feedback can be used if endpoint A has means to verify the feedback message (authentication and integrity). BR, Zhigang > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: April 03, 2002 6:33 AM > To: 'Hans Hannu (EPL)'; 'rohc@ietf.org' > Subject: RE: [rohc] sigcomp issue lejo-10 > > > Hi Hans, > > The receiving endpoint could certainly track the states that are > being accessed and attempt to guess whether explicit acks are needed > or not. However this might take quite a few RTTs, and the endpoint > would also have to download some new bytecode on the fly which is > quite costly. > > I believe that the format of the requested feedback should be as > follows: > > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ > | 0 | requested_feedback | | 1 | requested_feedback_length | > +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ > | | > : requested_feedback : > | | > +---+---+---+---+---+---+---+---+ > > The returned feedback format should be identical. The reason for the > above encoding is that the requested feedback does not have to be a > state identifier; any message identifier will suffice as long as the > sender does not reuse a MID before it has been acknowledged. The above > encoding is very efficient for the case that at most 128 distinct MIDs > are required (which is typically more than enough). > > The SigComp parameters (including the state identifiers for the state > created by the sender) should be announced similarly to SigComp-05. > > Regards, > > Richard > > > -----Original Message----- > > From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > > Sent: Wednesday, April 03, 2002 1:05 PM > > To: Price, Richard; 'rohc@ietf.org' > > Subject: RE: [rohc] sigcomp issue lejo-10 > > > > > > Hi Richard, > > > > > Even worse, we might end up with no ack scheme at all > > > because each endpoint expects the other endpoint to handle the > > > acknowledgements. > > > > Well, an endpoint could keep track of what states that are > > being requested/accessed by the remote endpoint so I do not > > think that will happen, but it would be a matter of implementation. > > > > Anyway, would the announcement information look something > > like below in SigComp-06 then? > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | UDVM_version | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SigComp parameters | > > : : > > : : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | n | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | id_length 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > : id_value_1 : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : : > > : : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | id_length n | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > : id_value_n : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Requested data length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > : Requested data : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Returned data length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > : Returned data : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > : reserved : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > BR > > /Hans H > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 4 06:20:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09747 for ; Thu, 4 Apr 2002 06:20:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21969; Thu, 4 Apr 2002 06:15:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21936 for ; Thu, 4 Apr 2002 06:15:44 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09673 for ; Thu, 4 Apr 2002 06:15:39 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34BFgs7022168 for ; Thu, 4 Apr 2002 13:15:42 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Apr 04 13:15:29 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 13:05:14 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'zhigang.c.liu@nokia.com'" , richard.price@roke.co.uk, rohc@ietf.org Subject: RE: [rohc] sigcomp issue lejo-10 Date: Thu, 4 Apr 2002 13:13:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org > It looks to me that we only need to standardize > some *encapsulation* format for feedback I think that this is what we're doing now. What is actually in the requested_feedback "announcement" field and how that data is formatted is up to the compressor to specify by uploading the UDVM code. BR /Hans H _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 4 15:28:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07596 for ; Thu, 4 Apr 2002 15:28:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29396; Thu, 4 Apr 2002 15:22:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29356 for ; Thu, 4 Apr 2002 15:22:41 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07343 for ; Thu, 4 Apr 2002 15:22:37 -0500 (EST) From: Narendra.Chaparala@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g34KPBH04551 for ; Thu, 4 Apr 2002 14:25:11 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Apr 2002 14:22:39 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 14:22:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 4 Apr 2002 14:22:07 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD6E1B95@daebe008.NOE.Nokia.com> Thread-Topic: [rohc] sigcomp -05: Multiload instruction Thread-Index: AcHb5jfRKARvfCLbSGu1gVA42tFv4gAL+0+w To: X-OriginalArrivalTime: 04 Apr 2002 20:22:07.0797 (UTC) FILETIME=[64951E50:01C1DC16] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA29361 Subject: [rohc] byte_copy_right Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit What's the motivation behind byte_copy_right pointing to the address immediately following the end of udvm buffer? Thank You, Narendra _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 5 00:58:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20111 for ; Fri, 5 Apr 2002 00:58:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28147; Fri, 5 Apr 2002 00:45:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28115 for ; Fri, 5 Apr 2002 00:45:55 -0500 (EST) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20005 for ; Fri, 5 Apr 2002 00:45:52 -0500 (EST) Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id g355jid26925; Fri, 5 Apr 2002 07:45:45 +0200 (MEST) From: "Dr. Carsten Bormann" To: , Subject: RE: [rohc] byte_copy_right Date: Fri, 5 Apr 2002 07:45:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <7CA3477F476D7F4FB82F02960B79CEBD6E1B95@daebe008.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit > What's the motivation behind byte_copy_right pointing to the > address immediately following the end of udvm buffer? Well, actually, it does not really matter how you delimit the area, so this is pretty much a non-consequential change (but one that changes the bits over the wire). That said, using the address of the next byte avoids having to compute/load/set something to an address minus one. e.g.: reserve circular_buffer (2048) :end_of_circular_buffer With the change, you can: MULTILOAD(0, 2, circular_buffer, end_of_circular_buffer) without address arithmetic acrobatics. Since the address of the next byte is more likely to be a power of two, the %-style operand optimizations are more likely to work. More generally speaking, a curt (terse/brusque/blunt) answer would be "because CS people just do it that way". Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 9 01:52:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18745 for ; Tue, 9 Apr 2002 01:52:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21316; Tue, 9 Apr 2002 01:49:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21287 for ; Tue, 9 Apr 2002 01:49:06 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18635 for ; Tue, 9 Apr 2002 01:49:00 -0400 (EDT) Received: from faraday (faraday.psl.com.sg [172.16.21.11]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with SMTP id g395hp806578 for ; Tue, 9 Apr 2002 13:43:51 +0800 (SGT) Message-ID: <001e01c1df89$f5616940$0b1510ac@psl.com.sg> From: "Lee lik sun" To: Date: Tue, 9 Apr 2002 13:46:56 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C1DFCD.036AB8A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [rohc] Questions on ROHC List Compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C1DFCD.036AB8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, for the XI items in the List Compression, the format is for PS =3D 0 X (1bit), Index (3 bit) PS=3D 1 X(1bit), Index(7 bit) my question is what is the function of this X bit in ET =3D 0,1,3 eg if X is not set, X =3D 0, but index =3D 3, what does it means? are we suppose to obtain the item from index 3 in the translation table? what if the index is empty? Please advise, thanks in advance regards Lee Lik Sun Panasonic Singapore Laboratories ------=_NextPart_000_001B_01C1DFCD.036AB8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
for the XI items in the List Compression, the format is
 
for PS =3D 0
X (1bit), Index (3 bit)
PS=3D 1
X(1bit), Index(7 bit)
 
my question is what is the function of this X bit in ET =3D = 0,1,3
 
eg
if X is not set, X =3D 0, but index =3D 3,
 
what does it means?
are we suppose to obtain the item from index 3 in the translation=20 table?
what if the index is empty?
 
Please advise, thanks in advance
 
regards
Lee Lik Sun
Panasonic Singapore Laboratories
 
 
------=_NextPart_000_001B_01C1DFCD.036AB8A0-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 9 11:49:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09859 for ; Tue, 9 Apr 2002 11:49:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28463; Tue, 9 Apr 2002 11:43:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22201 for ; Tue, 9 Apr 2002 02:05:29 -0400 (EDT) Received: from mail-jpn.microsoft.com (mail-jpn.microsoft.com [207.46.71.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26103 for ; Tue, 9 Apr 2002 02:05:25 -0400 (EDT) Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 15:04:55 +0900 Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Apr 2002 15:04:55 +0900 Received: from bjs-msg-01.fareast.corp.microsoft.com ([157.60.72.120]) by jpn-imc-01.fareast.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 15:04:55 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Tue, 9 Apr 2002 14:04:53 +0800 Message-ID: Thread-Topic: proposals for generic notation of compressed header Thread-Index: AcHfjHeZtsyPSnpiTySvIriLnwF7/Q== From: "Qian Zhang" To: "West, Mark (ITN)" Cc: X-OriginalArrivalTime: 09 Apr 2002 06:04:55.0135 (UTC) FILETIME=[786476F0:01C1DF8C] Subject: [rohc] proposals for generic notation of compressed header Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF8C.777C3E27" ------_=_NextPart_001_01C1DF8C.777C3E27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, As I promised in the MSP meeting, we would like to contribute on the generic compressed header notation part. =20 First, I would like to clarify some of our discussion about the notation part in MSP meeting. 1. Current stack encoding methods defined in EPIC-LITE should be removed from the generic notation.=20 As we all agreed that in the general notation part, in stead of describing how to group the related fields together, people only need to describe which fields can be grouped together for efficiently encoding. We can just explicitly describe it in the notation part. For example, in TCP/IP profile, the IP's reserved flag and TCP's reserved flag are encoded together, the notation can be written as follows: tcpip-reserved-flags =3D ip-reserved-flags tcp-reserved-flags =20 2. Refine the notation about FORMAT.=20 The FORMAT encoding method is used to create more than one set of compressed header formats. Notice that the first set of format is used as the default compressed format before the compressor chooses to change the format. In EPIC-LITE, an index flag is appended to the uncompressed header to indicate which set of formats is currently in use. Thus, all encoding methods are present in the IR(-DYN) packets, so an IR(-DYN) packet may be sent to change to a new set of compressed header formats. =20 For a generic notation, we propose to separate the functionalities between notation and the state machine for different header compression profile. In this way, the FORMAT change decision should be made by the state machine and only happens when the state machine jumps back to the IR state. =20 Secondly, we would like to propose some new notations for the generic notation of header compression. =20 Before we go deep into the notation for compressed header, we want to first give a more formal definition of the uncompressed packet header. A header is the control information of a message or packet of data. Suppose a record is a sequence of bits, each record has a corresponding type (or name). Moreover, a header can be formally defined as a sequence of records.=20 For example, TCP header can be defined as follows: =20 tcp-header :=3D source-port destination-port sequence-number acknowledgment-number data-offset reversed ecn control-bits window tcp-checksum urgent-pointer tcp-options source-port :=3D bits(16) destination-port :=3D bits(16) sequence-number :=3D bits(32) acknowledgment-number :=3D bits(32) data-offset :=3D bits(4) reversed :=3D bits(4) ecn :=3D CWR ECE control-bits :=3D URG ACK PSH RST SYN FIN CWR :=3D bits(1) ECE :=3D bits(1) URG :=3D bits(1) PSH :=3D bits(1) RST :=3D bits(1) SYN :=3D bits(1) FIN :=3D bits(1) window :=3D bits(16) tcp-checksum :=3D bits(16) urgent-pointer :=3D bits(16) tcp-options :=3D *(tcp-opt-end | tcp-opt-nop | tcp-opt-mss | tcp-opt-wscale | tcp-opt-sack-permitted | tcp-opt-sack | tcp-opt-timestamp | tcp-opt-generic) tcp-opt-end :=3D bits(8) tcp-opt-nop :=3D bits(8) tcp-opt-mss :=3D bits(32) tcp-opt-wscale :=3D bits(24) tcp-opt-sack-permitted :=3D bits(16) tcp-opt-sack :=3D bits(16) (tcp-opt-sack-block)+ tcp-opt-sack-block :=3D bits(64) =20 In most cases, the header consists of a sequence of records in which each one has a different type (or name) and appears in the header in the specified order , e.g. source-port, destination-port, etc. However, there exist records which may appear in any order, e.g., options in the tcp-options. Moreover, there may exist some records with the same type (or name) which occurs multi-times, e.g., NOP, SACK-BLOCK. We will refer to the later two cases as 'out-of-order-sequence' and 'repeat-sequence' respectively and the former one as 'in-order-sequence'. =20 EPIC-LITE uses Huffman compression to generate the indicator flags for each compressed header format. Each format is treated as one character in the Huffman character set. To determine the entire format set (the character set in Huffman compression), people must determine how many records (or fields) a header has and how many possible encoding methods there are for each records. For 'in-order-sequence', the format set can be calculated easily. However, for 'out-of-order-sequence' and 'repeat-sequence' cases, the calculation CANNOT be done easily and efficiently since there are types of records which can appear in any order or have more than one occurrence. The LIST encoding method in EPIC-LITE is introduced to handle these cases. For types of records which may appear multi-times, the LIST encoding method treat each occurrence of the same type of record as a new type of record and list the maximum occurrences in the set of encoding methods of LIST. For example, in RTP profile, the CSRC list field lists all possible 16 CSRC entries, in TCP profile, the SACK option lists all possible 4 SACK blocks. For types of records which may appear in any order, the LIST encoding method encodes the 'order' information and delivery it to the decompressor to make sure the compressed header can be decompressed correctly. However, as the number of types of records in the 'out-of-order-sequence' increases, LIST needs more bits to encode the 'order'. (roughly, if there are N types of records, N*log2(N) bits are needed.) If some types of records may appear more than one times, more bits are needed to represent the order in the LIST method. =20 From the above analysis, LIST encoding method is not an efficient encoding method for 'out-of-order-sequence' and 'repeat-sequence'. (Actually the agreement for this statement had been achieved in the discussion on the MSP meeting.) For example, in SCTP, the Selective Acknowledgment (SACK) chunk may contains thousands of Gap Ack Blocks and Duplicate TSNs. It's impossible to list thousands of them in the profile of SCTP. =20 =20 To propose more efficient encoding methods for 'out-of-order-sequence' and 'repeat-sequence', we first propose an improvement on the compressed header format. =20 The compressed header format in EPIC-LITE divides each compressed header into two parts: the indicator flags and the compressed fields as illustrated below: =20 +---+---+---+---+--------------------+--------------------+--- | 0 | 1 | 1 | 0 | Compressed Field 1 | Compressed Field 2 |... +---+---+---+---+--------------------+--------------------+--- \ \ / / \ / \ \ / / \ / Indicator Flags Compressed Fields =20 Our proposed compressed header format extends it to a more general format by introducing the concept of hierarchy. At the top level, each compressed header can be divided into also two parts: the indicator flags and the (sub) compressed headers. The indicator flags contain 0 or more bits and specify how to decompress those (sub) compressed header. The (sub) compressed header may be another level of compressed header or just the compressed value of the record. The structure of the proposed compressed header format can be illustrated as follows: =20 +---------------------- | compressed header ... +---------------------- / \ / \ =20 +-------+---------------------------+---------------------------+--- | flags | (sub) compressed header 1 | (sub) compressed header 2 | ... =20 +-------+---------------------------+---------------------------+--- / \ / \ +-------------+-------------------------------+--- | (sub) flags | (sub-sub) compressed header 1 | ... +-------------+-------------------------------+--- / \ / \ ..... =20 Note that, the compressed header format in EPIC-LITE can be viewed as the above header format with just one level, which is a special case of our proposed general compressed header format. =20 With the proposed compressed header format, the global format set of Huffman compressed, which contains all possible combinations of compressed methods of every field, is split into several format sets which is associated with each (sub) compressed header, and each format set can be tweaked into a manageable size. The complexity of finding indicator flags from compressing method of each field and vice versa can be alleviated in a divide-and-conquer way. =20 For 'out-of-order-sequence' and 'repeat-sequence', we propose two new encoding methods, SUB-TREE-0 and SUB-TREE-N, to handle them respectively. =20 SUB-TREE-0 =20 ABNF notation: "SUB-TREE-0(" "," *("," ) ")" =20 SUB-TREE-0 encoding method tries to compress a sequence of records with one ending flag. For example, tcp-options is a sequence of tcp options with END as the ending flag. =20 The first parameter probability indicates how often the method will be used. Note that, this probability only affects the format set of the same level the SUB-TREE-0 is used, it cannot affect the format set of the other levels. =20 The probability is followed by a set of encoding methods that can be used to compress individual records in the 'out-of-order-sequence'. The first also specify the ending flag of that sequence. =20 Using SUB-TREE-0, the order of different types of records is unnecessary to encode since the compressed headers also appear in the same order as the original records. SUB-TREE-0 encoding method will produce several (sub) compressed headers and generate a unique and compact indicator flag for each type of record listed in the sequence. =20 SUB-TREE-N =20 ABNF notation: "SUB-TREE-N(" "," "," ")" =20 SUB-TREE-N encoding method try to compress a sequence of the same type of records with a length field which is defined somewhere. For example, CSRC list entries and SACK blocks can be used with this method. SUB-TREE-N encoding method will produce several (sub) compressed headers. =20 The first parameter probability indicates how often the method will be used. Note that, this probability only affects the format set of the same level the SUB-TREE-N is used, it cannot affect the format set of the other levels. =20 The second parameter specifies the maximum occurrences of the type of record. =20 The third parameter is the encoding method used to compress the each record in the 'repeat-sequence'. =20 Using SUB-TREE-N, the multi-occurrences don't need notating in the profile. SUB-TREE-N will produce several (sub) compressed header, one of them is the number of the occurrences of the type of records, others are the compressed header for each occurrence of the type of records. =20 ----- Note that we can combine those two encoding methods into one method with an additional parameter to indicate the type of records ending approach. ----- TCP options field can be notated with these two new encoding methods as follows: =20 tcp-options-co =3D SUB-TREE-0(40%, tcp-opt-end, tcp-opt-nop, tcp-opt-timestamp, tcp-opt-sack, tcp-opt-generic) =20 tcp-options-dyn =3D SUB-TREE-0(100%, tcp-opt-end, tcp-opt-nop, tcp-opt-timestamp, tcp-opt-sack-permitted, tcp-opt-mss, tcp-opt-wscale, tcp-opt-generic) =20 tcp-opt-sack =3D SUB-TREE-N(100%, 4, tcp-opt-sack-block) =20 =20 Comments are welcome, =20 Best Regards Qian and Hongbin =20 =20 =20 =20 ------_=_NextPart_001_01C1DF8C.777C3E27 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

    As I promised in the MSP meeting, we would like to contribute on the = generic compressed header notation part.

 

   First, I would like to clarify some of our discussion about the notation part = in MSP meeting.

        1. Current stack encoding methods defined in EPIC-LITE should be = removed from the generic notation.

         As we all agreed that in the general notation part, in = stead of describing how to group the related fields together, people only need = to describe which fields can be grouped together for efficiently encoding. =  

         We can just explicitly describe it in the notation part.  For = example, in TCP/IP profile, the IP's reserved flag and TCP's reserved flag are = encoded together, the notation can be written as follows:

     tcpip-reserved-flags =3D ip-reserved-flags

          &nb= sp;        tcp-reserved-flags

 

        2. Refine the notation about = FORMAT.

         The FORMAT encoding method is used to create more than one set of = compressed header formats.   Notice that the first set of format is used = as the default compressed format before the compressor chooses to change the format.  In EPIC-LITE, an index flag is appended to the = uncompressed header to indicate which set of formats is currently in use.  Thus, = all encoding methods are present in the IR(-DYN) packets, so an IR(-DYN) = packet may be sent to change to a new set of compressed header formats. =   

         For a generic notation, we propose to separate the functionalities = between notation and the state machine for different header compression profile.  In this way, the FORMAT change decision should be made by the = state machine and only happens when the state machine jumps back to the IR = state.

 

    Secondly, we would like to propose = some new notations for the generic notation of header = compression.

 

Before we go deep into the notation for compressed header, we want to first = give a more formal definition of the uncompressed packet header.  A header = is the control information of a message or packet of data.  Suppose a = record is a sequence of bits, each record has a corresponding type (or name).  Moreover, a header can be formally defined as a sequence of records. =


For example, TCP header can be defined as follows:

 

tcp-header = :=3D source-port
          =     destination-port
      =         sequence-number
            =   acknowledgment-number
             =  data-offset
            &= nbsp; reversed
            &= nbsp; ecn
  =             c= ontrol-bits
   =            window<= br>     =           tcp-checksum<= br>      =          urgent-pointer
      =         tcp-options
source-port      :=3D bits(16)
destination-port   :=3D bits(16)
sequence-number    :=3D bits(32)
acknowledgment-number :=3D bits(32)
data-offset      :=3D bits(4)
reversed       :=3D bits(4)
ecn       :=3D CWR
         =     ECE
control-bits :=3D URG
            &= nbsp;   ACK
               &= nbsp;PSH
                RST
                SYN
                FIN
CWR          :=3D = bits(1)
ECE          :=3D = bits(1)
URG          :=3D = bits(1)
PSH          :=3D = bits(1)
RST          :=3D = bits(1)
SYN          :=3D = bits(1)
FIN          :=3D = bits(1)
window        :=3D bits(16)<= br> tcp-checksum     :=3D bits(16)
urgent-pointer    :=3D bits(16)
tcp-options :=3D *(tcp-opt-end | tcp-opt-nop | tcp-opt-mss
            &= nbsp;   | tcp-opt-wscale | tcp-opt-sack-permitted
              &= nbsp; | tcp-opt-sack | tcp-opt-timestamp
    =             | tcp-opt-generic)
tcp-opt-end      :=3D bits(8)
tcp-opt-nop      :=3D bits(8)
tcp-opt-mss      :=3D bits(32)
tcp-opt-wscale      :=3D bits(24)
tcp-opt-sack-permitted :=3D bits(16)
tcp-opt-sack      :=3D bits(16)
            &= nbsp;       (tcp-opt-sack-block)+
tcp-opt-sack-block  :=3D bits(64)

 

In most = cases, the header consists of a sequence of records in which each one has a = different type (or name) and appears in the header in the specified order , e.g.  = source-port, destination-port, etc.  However, there exist records which may = appear in any order, e.g., options in the tcp-options. Moreover, there may exist = some records with the same type (or name) which occurs multi-times, e.g., = NOP, SACK-BLOCK.  We will refer to the later two cases as 'out-of-order-sequence' and 'repeat-sequence' respectively and the = former one as 'in-order-sequence'.

 

EPIC-LITE = uses Huffman compression to generate the indicator flags for each compressed = header format.  Each format is treated as one character in the Huffman = character set.  To determine the entire format set (the character set in = Huffman compression), people must determine how many records (or fields) a = header has and how many possible encoding methods there are for each records. =  For 'in-order-sequence', the format set can be calculated easily. However, = for 'out-of-order-sequence' and 'repeat-sequence' cases, the calculation = CANNOT be done easily and efficiently since there are types of records which can = appear in any order or have more than one occurrence.   The LIST = encoding method in EPIC-LITE is introduced to handle these cases. For types of records = which may appear multi-times, the LIST encoding method treat each occurrence = of the same type of record as a new type of record and list the maximum = occurrences in the set of encoding methods of LIST.  For example, in RTP profile, = the CSRC list field lists all possible 16 CSRC entries, in TCP profile, the = SACK option lists all possible 4 SACK blocks.  For types of records = which may appear in any order, the LIST encoding method encodes the 'order' = information and delivery it to the decompressor to make sure the compressed header = can be decompressed correctly.  However, as the number of types of records = in the 'out-of-order-sequence' increases, LIST needs more bits to encode the = 'order'. (roughly, if there are N types of records, N*log2(N) bits are needed.) =  If some types of records may appear more than one times, more bits are = needed to represent the order in the LIST method.

 

From the = above analysis, LIST encoding method is not an efficient encoding method for 'out-of-order-sequence' and 'repeat-sequence'. (Actually the agreement = for this statement had been achieved in the discussion on the MSP meeting.) =  For example, in SCTP, the Selective Acknowledgment (SACK) chunk may contains = thousands of Gap Ack Blocks and Duplicate TSNs.  It's impossible to list = thousands of them in the profile of SCTP.  

 

To propose = more efficient encoding methods for 'out-of-order-sequence' and = 'repeat-sequence', we first propose an improvement on the compressed header = format.

 

The = compressed header format in EPIC-LITE divides each compressed header into two = parts: the indicator flags and the compressed fields as illustrated = below:

 

      +---+---+---+---+--------------------+--------------------+---
      | 0 | 1 | 1 | 0 | Compressed Field 1 | Compressed Field 2 |...
      +---+---+---+---+--------------------+--------------------+---
       \   = \     /   /            =       \     /
        \   \   /   /            =         \   /
       Indicator = Flags           &n= bsp; Compressed Fields

 

Our = proposed compressed header format extends it to a more general format by = introducing the concept of hierarchy. At the top level, each compressed header can be = divided into also two parts: the indicator flags and the (sub) compressed = headers. The indicator flags contain 0 or more bits and specify how to decompress = those (sub) compressed header. The (sub) compressed header may be another = level of compressed header or just the compressed value of the record. The = structure of the proposed compressed header format can be
illustrated as follows:

 

   +----------------------
   | compressed header   ...
   +----------------------
         /       \
        /         \
      +-------+---------------------------+---------------------------+---
      | flags | (sub) compressed header 1 | = (sub) compressed header 2 | ...
      +-------+---------------------------+---------------------------+---
     =          /       \
             /         \
      =  +-------------+-------------------------------+---
       | (sub) flags | (sub-sub) = compressed header 1 | ...
       +-------------+-------------------------------+---
            &= nbsp;          /       \
            &= nbsp;         /         \
            &= nbsp;           &n= bsp;   .....

 

Note that, = the compressed header format in EPIC-LITE can be viewed as the above header format with = just one level, which is a special case of our proposed general compressed = header format.

 

With the = proposed compressed header format, the global format set of Huffman compressed, = which contains all possible combinations of compressed methods of every = field,  is split into several format sets which is associated with each (sub) compressed header, and each format set can be tweaked into a manageable = size. The complexity of finding indicator flags from compressing method of = each field and vice versa can be alleviated in a divide-and-conquer = way.

 

For 'out-of-order-sequence' and 'repeat-sequence', we propose two new = encoding methods, SUB-TREE-0 and SUB-TREE-N, to handle them = respectively.

 
SUB-TREE-0

 

ABNF notation: = "SUB-TREE-0(" <probability> "," <encoding_name>
        *("," = <encoding_name>) ")"

 

SUB-TREE-0 = encoding method tries to compress a sequence of records with one ending flag. For example, tcp-options is a sequence of tcp options with END as the ending = flag.

 

The first = parameter probability indicates how often the method will be used. Note that, this probability only affects the format set of the same level the SUB-TREE-0 = is used, it cannot affect the format set of the other levels.

 

The = probability is followed by a set of encoding methods that can be used to compress = individual records in the 'out-of-order-sequence'. The first <encoding_name> = also specify the ending flag of that sequence.

 

Using = SUB-TREE-0, the order of different types of records is unnecessary to encode since = the compressed headers also appear in the same order as the original = records.  SUB-TREE-0 encoding method will produce several (sub) compressed headers = and generate a unique and compact indicator flag for each type of record = listed in the <encoding_name> sequence.

 


SUB-TREE-N

 

ABNF notation: = "SUB-TREE-N(" <probability> "," <value> "," = <encoding_name> ")"

 

SUB-TREE-N = encoding method try to compress a sequence of the same type of records with a length = field which is defined somewhere. For example, CSRC list entries and SACK = blocks can be used with this method. SUB-TREE-N encoding method will produce = several (sub) compressed headers.

 

The first = parameter probability indicates how often the method will be used. Note that, this probability only affects the format set of the same level the SUB-TREE-N = is used, it cannot affect the format set of the other levels.

 

The second = parameter specifies the maximum occurrences of the type of = record.

 

The third = parameter is the encoding method used to compress the each record in the 'repeat-sequence'.

 

Using = SUB-TREE-N, the multi-occurrences don't need notating in the profile. SUB-TREE-N = will produce several (sub) compressed header, one of them is the number of = the occurrences of the type of records, others are the compressed header for = each occurrence of the type of records.

 

-----

Note that = we can combine those two encoding methods into one method with an additional = parameter to indicate the type of records ending approach.

-----


TCP options field can be notated with these two new encoding methods as follows:

 

tcp-options-co =3D = SUB-TREE-0(40%,
            &= nbsp;  tcp-opt-end,
            &= nbsp;  tcp-opt-nop,
            &= nbsp;  tcp-opt-timestamp,
            &= nbsp;  tcp-opt-sack,
            &= nbsp;  tcp-opt-generic)

 

tcp-options-dyn =3D = SUB-TREE-0(100%,
            &= nbsp;  tcp-opt-end,
            &= nbsp;  tcp-opt-nop,
            &= nbsp;  tcp-opt-timestamp,
            &= nbsp;  tcp-opt-sack-permitted,
            &= nbsp;  tcp-opt-mss,
            &= nbsp;  tcp-opt-wscale,
            &= nbsp;  tcp-opt-generic)

 

tcp-opt-sack  =3D = SUB-TREE-N(100%,
            &= nbsp;  4,
            &= nbsp;  tcp-opt-sack-block)

 

 

 Comments are welcome,

 

Best = Regards

Qian and = Hongbin

 

 

 

 

=00 ------_=_NextPart_001_01C1DF8C.777C3E27-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Tue Apr 9 11:49:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09874 for ; Tue, 9 Apr 2002 11:49:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28509; Tue, 9 Apr 2002 11:43:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14360 for ; Tue, 9 Apr 2002 08:25:24 -0400 (EDT) Received: from hotmail.com (f307.law10.hotmail.com [64.4.14.182]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02967 for ; Tue, 9 Apr 2002 08:25:20 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Apr 2002 05:24:51 -0700 Received: from 207.46.71.13 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 09 Apr 2002 12:24:51 GMT X-Originating-IP: [207.46.71.13] From: "Qian Zhang" To: rohc@ietf.org Date: Tue, 09 Apr 2002 20:24:51 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Apr 2002 12:24:51.0727 (UTC) FILETIME=[8C3859F0:01C1DFC1] Subject: [rohc] proposals for generic notation of compressed header Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org -------------- I had sent this email twice; however, I can not find it in ROHC mailing list :-(. So I have to try again. -------------- Mark, As I promised in the MSP meeting, we would like to contribute on the generic compressed header notation part. First, I would like to clarify some of our discussion about the notation part in MSP meeting. 1. Current stack encoding methods defined in EPIC-LITE should be removed from the generic notation. As we all agreed that in the general notation part, in stead of describing how to group the related fields together, people only need to describe which fields can be grouped together for efficiently encoding. We can just explicitly describe it in the notation part. For example, in TCP/IP profile, the IP's reserved flag and TCP's reserved flag are encoded together, the notation can be written as follows: tcpip-reserved-flags = ip-reserved-flags tcp-reserved-flags 2. Refine the notation about FORMAT. The FORMAT encoding method is used to create more than one set of compressed header formats. Notice that the first set of format is used as the default compressed format before the compressor chooses to change the format. In EPIC-LITE, an index flag is appended to the uncompressed header to indicate which set of formats is currently in use. Thus, all encoding methods are present in the IR(-DYN) packets, so an IR(-DYN) packet may be sent to change to a new set of compressed header formats. For a generic notation, we propose to separate the functionalities between notation and the state machine for different header compression profile. In this way, the FORMAT change decision should be made by the state machine and only happens when the state machine jumps back to the IR state. Secondly, we would like to propose some new notations for the generic notation of header compression. Before we go deep into the notation for compressed header, we want to first give a more formal definition of the uncompressed packet header. A header is the control information of a message or packet of data. Suppose a record is a sequence of bits, each record has a corresponding type (or name). Moreover, a header can be formally defined as a sequence of records. For example, TCP header can be defined as follows: tcp-header := source-port destination-port sequence-number acknowledgment-number data-offset reversed ecn control-bits window tcp-checksum urgent-pointer tcp-options source-port := bits(16) destination-port := bits(16) sequence-number := bits(32) acknowledgment-number := bits(32) data-offset := bits(4) reversed := bits(4) ecn := CWR ECE control-bits := URG ACK PSH RST SYN FIN CWR := bits(1) ECE := bits(1) URG := bits(1) PSH := bits(1) RST := bits(1) SYN := bits(1) FIN := bits(1) window := bits(16) tcp-checksum := bits(16) urgent-pointer := bits(16) tcp-options := *(tcp-opt-end | tcp-opt-nop | tcp-opt-mss | tcp-opt-wscale | tcp-opt-sack-permitted | tcp-opt-sack | tcp-opt-timestamp | tcp-opt-generic) tcp-opt-end := bits(8) tcp-opt-nop := bits(8) tcp-opt-mss := bits(32) tcp-opt-wscale := bits(24) tcp-opt-sack-permitted := bits(16) tcp-opt-sack := bits(16) (tcp-opt-sack-block)+ tcp-opt-sack-block := bits(64) In most cases, the header consists of a sequence of records in which each one has a different type (or name) and appears in the header in the specified order , e.g. source-port, destination-port, etc. However, there exist records which may appear in any order, e.g., options in the tcp-options. Moreover, there may exist some records with the same type (or name) which occurs multi-times, e.g., NOP, SACK-BLOCK. We will refer to the later two cases as 'out-of-order-sequence' and 'repeat-sequence' respectively and the former one as 'in-order-sequence'. EPIC-LITE uses Huffman compression to generate the indicator flags for each compressed header format. Each format is treated as one character in the Huffman character set. To determine the entire format set (the character set in Huffman compression), people must determine how many records (or fields) a header has and how many possible encoding methods there are for each records. For 'in-order-sequence', the format set can be calculated easily. However, for 'out-of-order-sequence' and 'repeat-sequence' cases, the calculation CANNOT be done easily and efficiently since there are types of records which can appear in any order or have more than one occurrence. The LIST encoding method in EPIC-LITE is introduced to handle these cases. For types of records which may appear multi-times, the LIST encoding method treat each occurrence of the same type of record as a new type of record and list the maximum occurrences in the set of encoding methods of LIST. For example, in RTP profile, the CSRC list field lists all possible 16 CSRC entries, in TCP profile, the SACK option lists all possible 4 SACK blocks. For types of records which may appear in any order, the LIST encoding method encodes the 'order' information and delivery it to the decompressor to make sure the compressed header can be decompressed correctly. However, as the number of types of records in the 'out-of-order-sequence' increases, LIST needs more bits to encode the 'order'. (roughly, if there are N types of records, N*log2(N) bits are needed.) If some types of records may appear more than one times, more bits are needed to represent the order in the LIST method. From the above analysis, LIST encoding method is not an efficient encoding method for 'out-of-order-sequence' and 'repeat-sequence'. (Actually the agreement for this statement had been achieved in the discussion on the MSP meeting.) For example, in SCTP, the Selective Acknowledgment (SACK) chunk may contains thousands of Gap Ack Blocks and Duplicate TSNs. It's impossible to list thousands of them in the profile of SCTP. To propose more efficient encoding methods for 'out-of-order-sequence' and 'repeat-sequence', we first propose an improvement on the compressed header format. The compressed header format in EPIC-LITE divides each compressed header into two parts: the indicator flags and the compressed fields as illustrated below: +---+---+---+---+--------------------+--------------------+--- | 0 | 1 | 1 | 0 | Compressed Field 1 | Compressed Field 2 |... +---+---+---+---+--------------------+--------------------+--- \ \ / / \ / \ \ / / \ / Indicator Flags Compressed Fields Our proposed compressed header format extends it to a more general format by introducing the concept of hierarchy. At the top level, each compressed header can be divided into also two parts: the indicator flags and the (sub) compressed headers. The indicator flags contain 0 or more bits and specify how to decompress those (sub) compressed header. The (sub) compressed header may be another level of compressed header or just the compressed value of the record. The structure of the proposed compressed header format can be illustrated as follows: +---------------------- | compressed header ... +---------------------- / \ / \ +-------+---------------------------+---------------------------+--- | flags | (sub) compressed header 1 | (sub) compressed header 2 | ... +-------+---------------------------+---------------------------+--- / \ / \ +-------------+-------------------------------+--- | (sub) flags | (sub-sub) compressed header 1 | ... +-------------+-------------------------------+--- / \ / \ ..... Note that, the compressed header format in EPIC-LITE can be viewed as the above header format with just one level, which is a special case of our proposed general compressed header format. With the proposed compressed header format, the global format set of Huffman compressed, which contains all possible combinations of compressed methods of every field, is split into several format sets which is associated with each (sub) compressed header, and each format set can be tweaked into a manageable size. The complexity of finding indicator flags from compressing method of each field and vice versa can be alleviated in a divide-and-conquer way. For 'out-of-order-sequence' and 'repeat-sequence', we propose two new encoding methods, SUB-TREE-0 and SUB-TREE-N, to handle them respectively. SUB-TREE-0 ABNF notation: "SUB-TREE-0(" "," *("," ) ")" SUB-TREE-0 encoding method tries to compress a sequence of records with one ending flag. For example, tcp-options is a sequence of tcp options with END as the ending flag. The first parameter probability indicates how often the method will be used. Note that, this probability only affects the format set of the same level the SUB-TREE-0 is used, it cannot affect the format set of the other levels. The probability is followed by a set of encoding methods that can be used to compress individual records in the 'out-of-order-sequence'. The first also specify the ending flag of that sequence. Using SUB-TREE-0, the order of different types of records is unnecessary to encode since the compressed headers also appear in the same order as the original records. SUB-TREE-0 encoding method will produce several (sub) compressed headers and generate a unique and compact indicator flag for each type of record listed in the sequence. SUB-TREE-N ABNF notation: "SUB-TREE-N(" "," "," ")" SUB-TREE-N encoding method try to compress a sequence of the same type of records with a length field which is defined somewhere. For example, CSRC list entries and SACK blocks can be used with this method. SUB-TREE-N encoding method will produce several (sub) compressed headers. The first parameter probability indicates how often the method will be used. Note that, this probability only affects the format set of the same level the SUB-TREE-N is used, it cannot affect the format set of the other levels. The second parameter specifies the maximum occurrences of the type of record. The third parameter is the encoding method used to compress the each record in the 'repeat-sequence'. Using SUB-TREE-N, the multi-occurrences don't need notating in the profile. SUB-TREE-N will produce several (sub) compressed header, one of them is the number of the occurrences of the type of records, others are the compressed header for each occurrence of the type of records. ----- Note that we can combine those two encoding methods into one method with an additional parameter to indicate the type of records ending approach. ----- TCP options field can be notated with these two new encoding methods as follows: tcp-options-co = SUB-TREE-0(40%, tcp-opt-end, tcp-opt-nop, tcp-opt-timestamp, tcp-opt-sack, tcp-opt-generic) tcp-options-dyn = SUB-TREE-0(100%, tcp-opt-end, tcp-opt-nop, tcp-opt-timestamp, tcp-opt-sack-permitted, tcp-opt-mss, tcp-opt-wscale, tcp-opt-generic) tcp-opt-sack = SUB-TREE-N(100%, 4, tcp-opt-sack-block) Comments are welcome, Best Regards Qian and Hongbin _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 10 03:20:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12916 for ; Wed, 10 Apr 2002 03:20:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02818; Wed, 10 Apr 2002 03:11:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02780 for ; Wed, 10 Apr 2002 03:11:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12830 for ; Wed, 10 Apr 2002 03:10:58 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3A7B03G023317 for ; Wed, 10 Apr 2002 09:11:00 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 10 09:11:00 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTFPGL>; Wed, 10 Apr 2002 09:10:59 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'rohc@ietf.org'" Subject: RE: [rohc] sigcomp issue list Date: Wed, 10 Apr 2002 09:10:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi, The current sigcomp issue list can be found at: http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm This is a cut and paste summary of the work that the authors have done when trying to close the issues. Take a look and see what you think so that we can close the issues and submit the updated SigComp and SigComp-extended drafts. BR /Hans H > -----Original Message----- > From: Dr. Carsten Bormann [mailto:cabo@tzi.org] > Sent: den 18 mars 2002 20:30 > To: Dr. Carsten Bormann; rohc@ietf.org > Subject: RE: [rohc] sigcomp issue list > > > Sigcompers, > > I have compile some information from the various issues > posting that have > been on the mailing list. > I hope this is a useful recap for people preparing for > tomorrow's meeting. > I'm not claiming any of this is authoritative. > If you reply (please do), please change the subject to "sigcomp issue > xxx-nn", where xxx-nn is the issue number. > > Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 10 18:14:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03965 for ; Wed, 10 Apr 2002 18:14:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24108; Wed, 10 Apr 2002 18:12:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24076 for ; Wed, 10 Apr 2002 18:12:28 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03894 for ; Wed, 10 Apr 2002 18:12:20 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3AMCLs7008810; Thu, 11 Apr 2002 00:12:21 +0200 (MEST) Received: from arael27m58.eu.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id AAA19561; Thu, 11 Apr 2002 00:12:19 +0200 Date: Thu, 11 Apr 2002 00:19:22 +0200 (CEST) From: Vicknesan Ayadurai X-X-Sender: vick@caffreys.ericsson.se To: Kausik B Sinnaswamy cc: rohc@ietf.org Subject: Re: [rohc] Arctic RoHC In-Reply-To: <3CAA3F5F.1090506@effnet.com> Message-ID: <20020411000707.P2315-100000@caffreys.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi Kausik (cc other Arctic ROHC participants), It's taken a little while but we've put something up on the Arctic ROHC website to give you an idea of tests we can prepare for at the bake-off (see http://standards.ericsson.net/rohc under "Objectives"). However, this list doesn't cover all the items Kausik has proposed in his mail (below) and since there hasn't been any discussions on the mail-list, I'd like to inquire again if anyone else would like to test these, or other items not specified in the Objectives page of the website. Regards, vick. ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vicknesan AYADURAI Switchlab, Ericsson Research - Stockholm, Sweden Phone : +46 8 5087 8084 / Fax: +46 8 5087 8090 ++++++++++++++++++++++++++++++++++++++++++++++++++++ On Tue, 2 Apr 2002, Kausik B Sinnaswamy wrote: > Dear RoHCers > I am one of the implementors of RoHC at Effnet Inc. We would like to > inter operate the following at the bake off in Lulea in April: > > a. Profile 1: > 1. CSRC-List compression. > 2. IPv6 > 3. Outer header behavior > 4. Extension header list compression. > > b. Profiles: 0, 2 and 3. > > c. Robustness testing > 1. Use of LOSS_OPTION. > 2. Context damage adapting by the compressor. > > d. RoHC over PPP with Negotiation. > > Thanks > -Kausik > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Wed Apr 10 19:28:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05110 for ; Wed, 10 Apr 2002 19:28:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26901; Wed, 10 Apr 2002 19:23:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26868 for ; Wed, 10 Apr 2002 19:23:30 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05067 for ; Wed, 10 Apr 2002 19:23:21 -0400 (EDT) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <2VH24Z0W>; Thu, 11 Apr 2002 00:20:53 +0100 Received: from roke.co.uk (ras_fennel2.roke.co.uk [193.118.206.44]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2V2R41XH; Thu, 11 Apr 2002 00:20:39 +0100 From: "West, Mark (ITN)" To: Qian Zhang Cc: rohc@ietf.org Message-ID: <3CB4A632.80909@roke.co.uk> Date: Wed, 10 Apr 2002 21:53:06 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Subject: Re: [rohc] proposals for generic notation of compressed header References: Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Qian, Hongbin, Comments, as ever, inline... Cheers, Mark. Qian Zhang wrote: > Mark, > > As I promised in the MSP meeting, we would like to contribute on the > generic compressed header notation part. > Good! Thanks... > First, I would like to clarify some of our discussion about the > notation part in MSP meeting. > > 1. Current stack encoding methods defined in EPIC-LITE should be > removed from the generic notation. Yes. > > As we all agreed that in the general notation part, in stead of > describing how to group the related fields together, people only need to > describe which fields can be grouped together for efficiently encoding. > > We can just explicitly describe it in the notation part. For > example, in TCP/IP profile, the IP's reserved flag and TCP's reserved > flag are encoded together, the notation can be written as follows: > > tcpip-reserved-flags = ip-reserved-flags > > tcp-reserved-flags I don't think that it's *quite* that simple! The notation is capturing two things: the structure of the header and how to encode it. So, there has to be some way of identifying the IP reserved flags and the TCP reserved flags as well. The important point about removing the stack manipulation encodings is that they impose a particular solution (and one that's quite messy to use!) > 2. Refine the notation about FORMAT. > > The FORMAT encoding method is used to create more than one set > of compressed header formats. Notice that the first set of format is > used as the default compressed format before the compressor chooses to > change the format. In EPIC-LITE, an index flag is appended to the > uncompressed header to indicate which set of formats is currently in > use. Thus, all encoding methods are present in the IR(-DYN) packets, so > an IR(-DYN) packet may be sent to change to a new set of compressed > header formats. > > For a generic notation, we propose to separate the > functionalities between notation and the state machine for different > header compression profile. In this way, the FORMAT change decision > should be made by the state machine and only happens when the state > machine jumps back to the IR state. > Again, to summarise, we agreed that it was sensible to identify a default format set to use (in the absence of any other information). Although the index flag is in the current EPIC-lite draft it is not (I believe) actually necessary. So we may be able to get rid of this. However, you are right that the IR(-DYN) packets can be used to select the format. I don't think that you can necessarily insist that the format only changes when the state machine wants to change to IR state anyway. Consider a FORMAT encoding to handle the UDP checksum. This will have 2 choices 'with-checksum' and 'without-checksum'. Now, imagine a UDP flow changing its checksum behaviour. (Yes, it would be weird, but...) It is clear that the 'with-checksum' encoding will also be able to handle the 'without-checksum' case, and so the format change could be deferred. However, if the checksum starts being used on a flow that is using the 'without-checksum' encoding, the format transition is forced by the fact that it is the only way to encode the packet. However, for the more speculative 'this format might be more efficient than the current one' transitions, you may well be better off waiting for a natural transition to IR state... So, I think I *almost* agree (but with reservations)! > Secondly, we would like to propose some new notations for the > generic notation of header compression. > Now it gets interesting ;-) > > Before we go deep into the notation for compressed header, we want to > first give a more formal definition of the uncompressed packet header. > A header is the control information of a message or packet of data. > Suppose a record is a sequence of bits, each record has a corresponding > type (or name). Moreover, a header can be formally defined as a > sequence of records. > > For example, TCP header can be defined as follows: > [BNF-type definition snipped out to save space -- I agree with what's in it...] > > In most cases, the header consists of a sequence of records in which > each one has a different type (or name) and appears in the header in the > specified order , e.g. source-port, destination-port, etc. However, > there exist records which may appear in any order, e.g., options in the > tcp-options. Moreover, there may exist some records with the same type > (or name) which occurs multi-times, e.g., NOP, SACK-BLOCK. We will > refer to the later two cases as 'out-of-order-sequence' and > 'repeat-sequence' respectively and the former one as 'in-order-sequence'. > > EPIC-LITE uses Huffman compression to generate the indicator flags for > each compressed header format. Each format is treated as one character > in the Huffman character set. To determine the entire format set (the > character set in Huffman compression), people must determine how many > records (or fields) a header has and how many possible encoding methods > there are for each records. For 'in-order-sequence', the format set can > be calculated easily. However, for 'out-of-order-sequence' and > 'repeat-sequence' cases, the calculation CANNOT be done easily and > efficiently since there are types of records which can appear in any > order or have more than one occurrence. The LIST encoding method in > EPIC-LITE is introduced to handle these cases. For types of records > which may appear multi-times, the LIST encoding method treat each > occurrence of the same type of record as a new type of record and list > the maximum occurrences in the set of encoding methods of LIST. For > example, in RTP profile, the CSRC list field lists all possible 16 CSRC > entries, in TCP profile, the SACK option lists all possible 4 SACK > blocks. For types of records which may appear in any order, the LIST > encoding method encodes the 'order' information and delivery it to the > decompressor to make sure the compressed header can be decompressed > correctly. However, as the number of types of records in the > 'out-of-order-sequence' increases, LIST needs more bits to encode the > 'order'. (roughly, if there are N types of records, N*log2(N) bits are > needed.) If some types of records may appear more than one times, more > bits are needed to represent the order in the LIST method. > This analysis is quite thorough and correct, as far as it goes. However, it is clearly incorrect to say that LIST requires N*log2(N) bits to encode the order data for an N-ary LIST. It is true that the LIST encoding will generate this many bits for the 'order' meta-field. It is also true that the current set of encodings do not provide any obvious way of efficiently encoding the LIST order. Some thought leads us to recognise that the biggest problem is when the list is 'sparse'. That is, there are a lot of possible entries, but few of them will ever actually appear in the LIST. Sending a complete order for the entire list is clearly very wasteful. The simplest fix for this is to introduce an encoding (or set of encodings?) that are capable of more efficiently representing the order meta-field. For example, an encoding that sends order information only for those elements present in the list will be far more efficient. Anyway, apologies for this (not so) brief digression on list order encoding, and back to the discussion in hand... > > From the above analysis, LIST encoding method is not an efficient > encoding method for 'out-of-order-sequence' and 'repeat-sequence'. > (Actually the agreement for this statement had been achieved in the > discussion on the MSP meeting.) For example, in SCTP, the Selective > Acknowledgment (SACK) chunk may contains thousands of Gap Ack Blocks and > Duplicate TSNs. It's impossible to list thousands of them in the > profile of SCTP. > Ok - see above for a partial rebuttal. I sort of hope that an SCTP packet typically won't contain 'thousands of Gap Ack Blocks', but I take the point... > > > To propose more efficient encoding methods for 'out-of-order-sequence' > and 'repeat-sequence', we first propose an improvement on the compressed > header format. > > The compressed header format in EPIC-LITE divides each compressed header > into two parts: the indicator flags and the compressed fields as > illustrated below: > > +---+---+---+---+--------------------+--------------------+--- > | 0 | 1 | 1 | 0 | Compressed Field 1 | Compressed Field 2 |... > +---+---+---+---+--------------------+--------------------+--- > \ \ / / \ / > \ \ / / \ / > Indicator Flags Compressed Fields > > Our proposed compressed header format extends it to a more general > format by introducing the concept of hierarchy. At the top level, each > compressed header can be divided into also two parts: the indicator > flags and the (sub) compressed headers. The indicator flags contain 0 or > more bits and specify how to decompress those (sub) compressed header. > The (sub) compressed header may be another level of compressed header or > just the compressed value of the record. The structure of the proposed > compressed header format can be > illustrated as follows: > > +---------------------- > | compressed header ... > +---------------------- > / \ > / \ > +-------+---------------------------+---------------------------+--- > | flags | (sub) compressed header 1 | (sub) compressed header 2 | ... > +-------+---------------------------+---------------------------+--- > / \ > / \ > +-------------+-------------------------------+--- > | (sub) flags | (sub-sub) compressed header 1 | ... > +-------------+-------------------------------+--- > / \ > / \ > ..... > > Note that, the compressed header format in EPIC-LITE can be viewed as > the above header format with just one level, which is a special case of > our proposed general compressed header format. > My immediate reaction to this is that it is more of an encoding rule issue than a notation rule issue. (Although I'm prepared to be persuaded otherwise!) Whatever, it's an interesting thought, so let's follow it... > > With the proposed compressed header format, the global format set of > Huffman compressed, which contains all possible combinations of > compressed methods of every field, is split into several format sets > which is associated with each (sub) compressed header, and each format > set can be tweaked into a manageable size. The complexity of finding > indicator flags from compressing method of each field and vice versa can > be alleviated in a divide-and-conquer way. > I'm not sure what you mean by 'complexity' in this context? In sheer processing terms, it is clear that this approach is less efficient since you have to perform far more Huffman encoding/decoding operations. (Method selection is still linear w.r.t. number of fields and mapping to a Huffman code is near enough constant time regardless of the number of fields involved) It is also clear that splitting the encoding up into multiple Huffman codes is less efficient than treating everything as a single Huffman code. > > For 'out-of-order-sequence' and 'repeat-sequence', we propose two new > encoding methods, SUB-TREE-0 and SUB-TREE-N, to handle them respectively. > > SUB-TREE-0 > > ABNF notation: "SUB-TREE-0(" "," > *("," ) ")" > > SUB-TREE-0 encoding method tries to compress a sequence of records with > one ending flag. For example, tcp-options is a sequence of tcp options > with END as the ending flag. > > The first parameter probability indicates how often the method will be > used. Note that, this probability only affects the format set of the > same level the SUB-TREE-0 is used, it cannot affect the format set of > the other levels. > When you say 'how often the method will be used', are you referring to the SUB-TREE-0 method itself? And, if so, what other method could be given as an alternative? > > The probability is followed by a set of encoding methods that can be > used to compress individual records in the 'out-of-order-sequence'. The > first also specify the ending flag of that sequence. > (A minor point, but...) I'm not sure that the idea of specifying an 'ending flag' is as flexible as the length-based approach that we currently have. For example, how would you apply this to SCTP chunk headers? > > Using SUB-TREE-0, the order of different types of records is unnecessary > to encode since the compressed headers also appear in the same order as > the original records. SUB-TREE-0 encoding method will produce several > (sub) compressed headers and generate a unique and compact indicator > flag for each type of record listed in the sequence. > So, are you saying that each given as a parameter to the SUB-TREE-0 method is treated as a 'sub compressed-header'? Assuming that this is the case (apologies if I've mis-understood), a few questions... - how are the sub-header indicators generated? (if based on Huffman codes, where do the probabilities come from?) - following on, what probability would you specify for (e.g.) the 'timestamp' option which, essentially, is either always present or never present - surely this is going to incur a minimum 1-bit overhead per entry in the list, per packet? > > SUB-TREE-N > > ABNF notation: "SUB-TREE-N(" "," "," > ")" > > SUB-TREE-N encoding method try to compress a sequence of the same type > of records with a length field which is defined somewhere. For example, > CSRC list entries and SACK blocks can be used with this method. > SUB-TREE-N encoding method will produce several (sub) compressed headers. > > The first parameter probability indicates how often the method will be > used. Note that, this probability only affects the format set of the > same level the SUB-TREE-N is used, it cannot affect the format set of > the other levels. > Same question as before regarding the parameter. > > > The second parameter specifies the maximum occurrences of the type of > record. > > The third parameter is the encoding method used to compress the each > record in the 'repeat-sequence'. > I feel obliged to point out that it is a trivial notational tweak to introduce an encoding based on the current LIST encoding that specifies a repeat of up to 'N' items... > Using SUB-TREE-N, the multi-occurrences don't need notating in the > profile. SUB-TREE-N will produce several (sub) compressed header, one of > them is the number of the occurrences of the type of records, others are > the compressed header for each occurrence of the type of records. > To pick a simple example, the CSRC list for RTP, how does this handle insertion or deletion? Imagine I have a list of 6 CSRC entries. Now imagine that an entry is inserted or deleted at index 1. With this approach, do all entries after the point of change need to be re-encoded? And, again, if a Huffman token is used for each entry, doesn't this introduce a fixed minimum 1-bit overhead per entry per packet? To re-iterate this efficiency point, one of the issues with using Huffman codes is that they are maximally efficient when everything is folded into the one token. I accept that splitting the information across multiple codes adds some flexibility, but it also sacrifices efficiency. > ----- > > Note that we can combine those two encoding methods into one method with > an additional parameter to indicate the type of records ending approach. > This is minor notational issue. (But, for the record, my programming background tends to prefer different methods rather than excessive parameterisation...) > ----- > > > TCP options field can be notated with these two new encoding methods as > follows: > > tcp-options-co = SUB-TREE-0(40%, > tcp-opt-end, > tcp-opt-nop, > tcp-opt-timestamp, > tcp-opt-sack, > tcp-opt-generic) > > tcp-options-dyn = SUB-TREE-0(100%, > tcp-opt-end, > tcp-opt-nop, > tcp-opt-timestamp, > tcp-opt-sack-permitted, > tcp-opt-mss, > tcp-opt-wscale, > tcp-opt-generic) > > tcp-opt-sack = SUB-TREE-N(100%, > 4, > tcp-opt-sack-block) > > > Comments are welcome, > > Best Regards > > Qian and Hongbin > > Well, I've made plenty of specific comments above. As a more general comment on the 3rd part of this e-mail, regarding list encoding, I think it is clear that there is some more thinking to do on this. So, I would also encourage more comments and suggestions... -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 (Yes, I do know that my disclaimer is in an attachment. And, no, I didn't ask for it to be that way) --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 11 08:15:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25102 for ; Thu, 11 Apr 2002 08:15:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11652; Thu, 11 Apr 2002 07:50:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11622 for ; Thu, 11 Apr 2002 07:50:14 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24694 for ; Thu, 11 Apr 2002 07:50:11 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3BBoBs7025640 for ; Thu, 11 Apr 2002 13:50:12 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Apr 11 13:50:04 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Apr 2002 13:39:43 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'rohc@ietf.org'" Date: Thu, 11 Apr 2002 13:49:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] sigcomp issue cabo-11 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi, Could we close cabo-11 with the motivation given by Richard? BR /Hans H > > -----Original Message----- > > From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > > Sent: den 10 april 2002 09:11 > > To: 'rohc@ietf.org' > > Subject: RE: [rohc] sigcomp issue list > > > > > > Hi, > > > > The current sigcomp issue list can be found at: > > > http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm > > > > This is a cut and paste summary of the work that the authors > > have done when trying to close the issues. > > Take a look and see what you think so that we can close the > > issues and submit the updated SigComp and SigComp-extended drafts. > > > > BR > > /Hans H > > > > > -----Original Message----- > > > From: Dr. Carsten Bormann [mailto:cabo@tzi.org] > > > Sent: den 18 mars 2002 20:30 > > > To: Dr. Carsten Bormann; rohc@ietf.org > > > Subject: RE: [rohc] sigcomp issue list > > > > > > > > > Sigcompers, > > > > > > I have compile some information from the various issues > > > posting that have > > > been on the mailing list. > > > I hope this is a useful recap for people preparing for > > > tomorrow's meeting. > > > I'm not claiming any of this is authoritative. > > > If you reply (please do), please change the subject to > > "sigcomp issue > > > xxx-nn", where xxx-nn is the issue number. > > > > > > 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 > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 11 08:24:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25318 for ; Thu, 11 Apr 2002 08:24:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11519; Thu, 11 Apr 2002 07:46:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11488 for ; Thu, 11 Apr 2002 07:46:34 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24645 for ; Thu, 11 Apr 2002 07:46:31 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3BBkW3G029618 for ; Thu, 11 Apr 2002 13:46:32 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Apr 11 13:46:19 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Apr 2002 13:35:57 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'rohc@ietf.org'" Date: Thu, 11 Apr 2002 13:45:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] sigcomp issue rp-8 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org I suggest that we consider rp-8 to be closed with the motivation that Richard has given. BR /Hans H > -----Original Message----- > From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > Sent: den 10 april 2002 09:11 > To: 'rohc@ietf.org' > Subject: RE: [rohc] sigcomp issue list > > > Hi, > > The current sigcomp issue list can be found at: > http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm > > This is a cut and paste summary of the work that the authors > have done when trying to close the issues. > Take a look and see what you think so that we can close the > issues and submit the updated SigComp and SigComp-extended drafts. > > BR > /Hans H > > > -----Original Message----- > > From: Dr. Carsten Bormann [mailto:cabo@tzi.org] > > Sent: den 18 mars 2002 20:30 > > To: Dr. Carsten Bormann; rohc@ietf.org > > Subject: RE: [rohc] sigcomp issue list > > > > > > Sigcompers, > > > > I have compile some information from the various issues > > posting that have > > been on the mailing list. > > I hope this is a useful recap for people preparing for > > tomorrow's meeting. > > I'm not claiming any of this is authoritative. > > If you reply (please do), please change the subject to > "sigcomp issue > > xxx-nn", where xxx-nn is the issue number. > > > > 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 rohc-admin@ietf.org Thu Apr 11 08:31:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25516 for ; Thu, 11 Apr 2002 08:31:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12968; Thu, 11 Apr 2002 08:20:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12938 for ; Thu, 11 Apr 2002 08:20:02 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25192 for ; Thu, 11 Apr 2002 08:19:58 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3BCJxs7013949 for ; Thu, 11 Apr 2002 14:19:59 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 11 14:19:58 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTH3R6>; Thu, 11 Apr 2002 14:19:58 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'rohc@ietf.org'" Date: Thu, 11 Apr 2002 14:19:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] sigcomp issue sugar-5/cabo-8 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi, As Richard explains in his "action" to sugar-5. With the coming SigComp-06 a compressor is allocated a certain state_memory_size, and states are automatically deleted once the memory becomes full. The order in which the states are to be deleted can be set by a new parameter in the END-MESSAGE instruction called state_retention_priority and states with lower priority are deleted first. If there is a tie the state that was created first are deleted. As it is the decompressing side that assigns and announce the state_memory_size to the compressing endpoint it would not assign more memory than it can afford. So, the intention with the STATE-FREE instruction (let the compressor help the decompressor by freeing up state memory) are made somewhat "unnecessary". I suggest that we close sugar-5 and cabo-8. BR /Hans H > > > > > > Hi, > > > > The current sigcomp issue list can be found at: > > > http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm > > > > This is a cut and paste summary of the work that the authors > > have done when trying to close the issues. > > Take a look and see what you think so that we can close the > > issues and submit the updated SigComp and SigComp-extended drafts. > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 11 10:53:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28830 for ; Thu, 11 Apr 2002 10:53:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19837; Thu, 11 Apr 2002 10:37:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19806 for ; Thu, 11 Apr 2002 10:37:27 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28335 for ; Thu, 11 Apr 2002 10:37:23 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3BEbjs11173 for ; Thu, 11 Apr 2002 09:37:45 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Apr 2002 09:37:15 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 11 Apr 2002 09:36:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8 Date: Thu, 11 Apr 2002 09:36:22 -0500 Message-ID: Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8 Thread-Index: AcHhU98xRubrx5w5RuaN5duAnys8ywAC3s0Q To: , X-OriginalArrivalTime: 11 Apr 2002 14:36:23.0192 (UTC) FILETIME=[40B9D980:01C1E166] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA19807 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit Hi, I think we still need STATE_FREE instruction. Once a compressor assigns state_retention_priority to a state and sends it out, there is no way to modify it. STATE_FREE allows the compressor to free a state that wouldn't be freed by the assigned priority (i.e. the lowest one). Zhigang > -----Original Message----- > From: ext Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > Sent: April 11, 2002 7:19 AM > To: 'rohc@ietf.org' > Subject: [rohc] sigcomp issue sugar-5/cabo-8 > > > Hi, > > As Richard explains in his "action" to sugar-5. With the > coming SigComp-06 a compressor is allocated a certain > state_memory_size, and states are automatically deleted once > the memory becomes full. The order in which the states are to > be deleted can be set by a new parameter in the END-MESSAGE > instruction called state_retention_priority and states with > lower priority are deleted first. If there is a tie the state > that was created first are deleted. > > As it is the decompressing side that assigns and announce the > state_memory_size to the compressing endpoint it would not > assign more memory than it can afford. So, the intention with > the STATE-FREE instruction (let the compressor help the > decompressor by freeing up state memory) are made somewhat > "unnecessary". > > I suggest that we close sugar-5 and cabo-8. > > BR > /Hans H > > > > > > > > > > Hi, > > > > > > The current sigcomp issue list can be found at: > > > > > > http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm > > > > > > This is a cut and paste summary of the work that the authors > > > have done when trying to close the issues. > > > Take a look and see what you think so that we can close the > > > issues and submit the updated SigComp and SigComp-extended drafts. > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 11 12:32:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05125 for ; Thu, 11 Apr 2002 12:32:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27320; Thu, 11 Apr 2002 12:10:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05782 for ; Thu, 11 Apr 2002 05:31:02 -0400 (EDT) Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22882 for ; Thu, 11 Apr 2002 05:30:52 -0400 (EDT) Received: from ecvwall1.wipro.com (venus.easi.soft.net [164.164.23.6]) by wiproecmx2.wipro.com (8.11.3/8.11.3) with SMTP id g3B9Tmr03694 for ; Thu, 11 Apr 2002 14:59:58 +0530 (IST) Received: from m2vwall3.wipro.com ([164.164.29.237]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUED0D00.604 for ; Thu, 11 Apr 2002 14:59:01 +0530 Received: from 164.164.23.9 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Thu, 11 Apr 2002 14:49:04 +0530 Received: from ecvwall1.wipro.com ([164.164.23.6]) by mailstore.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUECJH00.81N for ; Thu, 11 Apr 2002 14:48:53 +0530 Received: from wipro.com ([10.113.1.100]) by ggnmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GUECIN00.B0W for ; Thu, 11 Apr 2002 14:48:23 +0530 Message-ID: <3CB5549A.DB0DC67D@wipro.com> Date: Thu, 11 Apr 2002 14:47:14 +0530 From: Lalit Bhasin Organization: WIPRO TECHNOLOGY X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ea3c3c3e-4d27-11d6-a942-00b0d0d06be8" Subject: [rohc] rohc query Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-ea3c3c3e-4d27-11d6-a942-00b0d0d06be8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi all, In case of IPv4-IPv4 tunneling, if the RND and RND2 flags are 0, how is the encoded IP-ID bits of the outer IPv4 header sent in the type 0,1 and 2 packets. The base header of these packets only carry the encoded IP-ID bits of inner IPv4 header. thanks in advance.. Lalit ------=_NextPartTM-000-ea3c3c3e-4d27-11d6-a942-00b0d0d06be8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-ea3c3c3e-4d27-11d6-a942-00b0d0d06be8-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 11 12:42:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05440 for ; Thu, 11 Apr 2002 12:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28549; Thu, 11 Apr 2002 12:34:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28520 for ; Thu, 11 Apr 2002 12:34:03 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05169 for ; Thu, 11 Apr 2002 12:33:59 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3BGaYH24718 for ; Thu, 11 Apr 2002 11:36:34 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Apr 2002 11:33:58 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 11 Apr 2002 11:32:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 11 Apr 2002 11:32:52 -0500 Message-ID: Thread-Topic: [rohc] sigcomp issue list Thread-Index: AcHgXygr1k9Y8KYQTlqdXn76VktjgQBDnc8Q To: , X-OriginalArrivalTime: 11 Apr 2002 16:32:53.0094 (UTC) FILETIME=[87084060:01C1E176] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA28521 Subject: [rohc] sigcomp issue zliu-3: cannot recovery from decompression failure ? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit Thanks Hans for a good summary on existing issues. I have to bring up one more as zliu-3 (I remember this has been somewhat discussed in different occasions but no follow up): how does SigComp recover from a decompression failure caused by reference to a corrupted or lost states (e.g. due to system failure at decompressor)? The problem is that the decompressor cannot send NACK to the sending compressor indicating such a failure because it does not know to whom it should send the NACK. The endpoint ID that sent a SigComp message can only be derived *after* the message is successfully decompressed due to security reasons. A potential deadlock? Possible answers: 1) Let's forget about it as it rarely happens. 2) The application will resend the message. The compressor can detect this and assume it is caused by decompression failure and fallback to no state for compression of this and subsequent message. However, this failure could be caused by message loss or corruption. Then the compression efficiency is unnecessarily sacrificed. 3) Find a way to enable NACK if possible at all. 4) Let's forget about it as it is unsolvable. I have no good idea and would like to hear opinions from the WG. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Thu Apr 11 21:38:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26399 for ; Thu, 11 Apr 2002 21:38:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00441; Thu, 11 Apr 2002 21:22:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00410 for ; Thu, 11 Apr 2002 21:22:52 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24251 for ; Thu, 11 Apr 2002 21:22:47 -0400 (EDT) Received: from faraday (faraday.psl.com.sg [172.16.21.11]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with SMTP id g3C1HK823201; Fri, 12 Apr 2002 09:17:20 +0800 (SGT) Message-ID: <001e01c1e1c0$39a88380$0b1510ac@psl.com.sg> From: "Lee lik sun" To: "Lalit Bhasin" , References: <3CB5549A.DB0DC67D@wipro.com> Subject: Re: [rohc] rohc query Date: Fri, 12 Apr 2002 09:20:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit Hi Lalit & all, Please correct my understanding if i am wrong. IF both RND & RND2 flags are 0. encoded IP-ID bits of the inner IPv4 header can sent in the type 0,1 & 2. But the IP-ID of the outer IPV4 header will have to be sent with an extension 3 with the Outer IP header flag (ip2) set and the IP-ID is sent uncompressed with I2 of the Outer IP header flag set. thanks & regards LEE lik sun ----- Original Message ----- From: Lalit Bhasin To: Sent: Thursday, April 11, 2002 5:17 PM Subject: [rohc] rohc query > hi all, > In case of IPv4-IPv4 tunneling, if the RND and RND2 flags are 0, > how is the encoded IP-ID bits of the outer IPv4 header > sent in the type 0,1 and 2 packets. The base header of these packets > only carry the encoded IP-ID bits of inner IPv4 header. > thanks in advance.. > Lalit > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 04:07:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19144 for ; Fri, 12 Apr 2002 04:07:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28625; Fri, 12 Apr 2002 03:44:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27311 for ; Fri, 12 Apr 2002 03:21:28 -0400 (EDT) Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14209 for ; Fri, 12 Apr 2002 03:21:07 -0400 (EDT) Received: from ecvwall1.wipro.com (venus.easi.soft.net [164.164.23.6]) by wiproecmx2.wipro.com (8.11.3/8.11.3) with SMTP id g3C765r24216 for ; Fri, 12 Apr 2002 12:36:05 +0530 (IST) Received: from m2vwall3.wipro.com ([164.164.29.237]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUG11400.GKS for ; Fri, 12 Apr 2002 12:35:28 +0530 Received: from 164.164.23.9 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 12:31:49 +0530 Received: from ecvwall1.wipro.com ([164.164.23.6]) by mailstore.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUG0UW00.E2R for ; Fri, 12 Apr 2002 12:31:44 +0530 Received: from wipro.com ([10.113.1.100]) by ggnmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GUG0UK00.S1S for ; Fri, 12 Apr 2002 12:31:32 +0530 Message-ID: <3CB68607.84F187D4@wipro.com> Date: Fri, 12 Apr 2002 12:30:23 +0530 From: Lalit Bhasin Organization: WIPRO TECHNOLOGY X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d94a3ae6-4dde-11d6-a942-00b0d0d06be8" Subject: [rohc] segmentation issue.... Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org ------=_NextPartTM-000-d94a3ae6-4dde-11d6-a942-00b0d0d06be8 Content-Type: multipart/alternative; boundary="------------15762720FBE65BD50F05C74E" --------------15762720FBE65BD50F05C74E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi all, As per RFC 3095 Section 5.2.5.2 SEGMENTATION PROTOCOL, the Segment header doesn't carry a CID. In the same section, later it is written that the CID is derived from the initial octets of the reconstructed unit. These two statements are contradicting each other. It is not clear that why the CID should not be a part of the Segment header. Regds, Lalit Bhasin -- ******************************* LALIT KUMAR BHASIN WIPRO TECHNOLOGIES GURGAON. Ph. 0124-6398465-69 Ext 2019 9810419594 ******************************** --------------15762720FBE65BD50F05C74E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi all,
   As per RFC 3095 Section 5.2.5.2 SEGMENTATION PROTOCOL, the Segment header doesn't carry a CID.
In the same section, later it is written that the CID is derived from the initial octets of the reconstructed unit. These two
statements are contradicting each other. It is not clear that why the CID should not be a part of the Segment header.

Regds,
Lalit  Bhasin 

-- 

*******************************
LALIT KUMAR BHASIN
WIPRO TECHNOLOGIES
GURGAON.
Ph. 0124-6398465-69 Ext 2019
    9810419594
********************************
  --------------15762720FBE65BD50F05C74E-- ------=_NextPartTM-000-d94a3ae6-4dde-11d6-a942-00b0d0d06be8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-d94a3ae6-4dde-11d6-a942-00b0d0d06be8-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 04:27:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20728 for ; Fri, 12 Apr 2002 04:27:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00338; Fri, 12 Apr 2002 04:17:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00307 for ; Fri, 12 Apr 2002 04:17:29 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20052 for ; Fri, 12 Apr 2002 04:17:25 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3C8HR3G010356 for ; Fri, 12 Apr 2002 10:17:27 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Apr 12 10:17:09 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Apr 2002 10:06:46 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Date: Fri, 12 Apr 2002 10:17:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompression fail ure ? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org > how does > SigComp recover from a decompression failure caused by > reference to a corrupted or lost states (e.g. due to system > failure at decompressor)? > > The problem is that the decompressor cannot send NACK to the > sending compressor indicating such a failure because it > does not know to whom it should send the NACK. The endpoint ID > that sent a SigComp message can only be derived *after* > the message is successfully decompressed due to security > reasons. A potential deadlock? I would say that the potential deadlock depends on how your implementation behaves. > Possible answers: > 1) Let's forget about it as it rarely happens. It is probably true that it rarely happens, but one (at least the implementer) should not forget about it. > 2) The application will resend the message. The compressor > can detect this and assume it is caused by decompression > failure and fallback to no state for compression of this > and subsequent message. This seems like a solutions that would work. > However, this failure could be > caused by message loss or corruption. True. > Then the compression > efficiency is unnecessarily sacrificed. A compressor implementation would have to weigh the possibilities that the message is resent due to decompression failure, message loss or corruption. Then it should decide in which form it should resend the message; compressed, uncompressed, "restarting" compressed message. > 3) Find a way to enable NACK if possible at all. This seems to be hard because of the security reasons. > 4) Let's forget about it as it is unsolvable. You could use 2) above. > I have no good idea and would like to hear opinions from the WG. Well, I think that 2) do sounds like a good idea. In my opinion that would not be a standardization issue for the ROHC WG, but rather an implementation issue -> "implementers guide". BR, /Hans H > BR, > Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 05:25:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26155 for ; Fri, 12 Apr 2002 05:25:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02872; Fri, 12 Apr 2002 05:09:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02841 for ; Fri, 12 Apr 2002 05:09:43 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24561 for ; Fri, 12 Apr 2002 05:09:39 -0400 (EDT) From: Robert.Sugar@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3C99s519319 for ; Fri, 12 Apr 2002 12:09:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 12 Apr 2002 12:09:37 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 12 Apr 2002 12:09:37 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 12:09:37 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 12 Apr 2002 11:09:35 +0200 Message-ID: <21B200DF0688CC45ACF38F49D2279832063717@buebe002.NOE.Nokia.com> Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8 Thread-Index: AcHhU94/IQoiU1vHTKCNGu5ZR7XuRQAqO9Ig To: X-OriginalArrivalTime: 12 Apr 2002 09:09:37.0113 (UTC) FILETIME=[C5015C90:01C1E201] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA02842 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit Hi, Thanks for collecting the issues, it is much clearer this way. Some more comments on the STATE_FREE discussion... Robert > -----Original Message----- > From: ext Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > Sent: 11. April 2002 14:19 > To: 'rohc@ietf.org' > Subject: [rohc] sigcomp issue sugar-5/cabo-8 > > > Hi, > > As Richard explains in his "action" to sugar-5. With the > coming SigComp-06 a compressor is allocated a certain > state_memory_size, and states are automatically deleted once > the memory becomes full. I do not see why we always have to use the full allocated memory when in fact we might not need that much all the time. > The order in which the states are to > be deleted can be set by a new parameter in the END-MESSAGE > instruction called state_retention_priority and states with > lower priority are deleted first. If there is a tie the state > that was created first are deleted. > > As it is the decompressing side that assigns and announce the > state_memory_size to the compressing endpoint it would not > assign more memory than it can afford. In many cases memory handling is not that rigid. The decompressor can "afford" more memory if that boosts the compression, especially if they level off with the ones with smaller memory need (eg. in case of a SIP proxy). Some algorithms generally need more memory than others and announcements do not take that into account as the compression algorithm is chosen by the compressor and the memory size is chosen by the decompressor. > So, the intention with > the STATE-FREE instruction (let the compressor help the > decompressor by freeing up state memory) are made somewhat > "unnecessary". > I agree with Zhigang that we still need STATE_FREE, especially because the compressor might not know in advance (when setting the priority) which states will be the most disposable ones. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 06:09:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00845 for ; Fri, 12 Apr 2002 06:09:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04756; Fri, 12 Apr 2002 05:54:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04721 for ; Fri, 12 Apr 2002 05:54:34 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29185 for ; Fri, 12 Apr 2002 05:54:30 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3C9sX3G015927 for ; Fri, 12 Apr 2002 11:54:33 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Apr 12 11:54:06 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Apr 2002 11:43:43 +0200 Message-ID: From: "Hans Hannu (EPL)" To: "'Robert.Sugar@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8 Date: Fri, 12 Apr 2002 11:53:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi, > > As Richard explains in his "action" to sugar-5. With the > > coming SigComp-06 a compressor is allocated a certain > > state_memory_size, and states are automatically deleted once > > the memory becomes full. > > I do not see why we always have to use the full > allocated memory when in fact we might not need that much all > the time. A compressor needs to know what state memory that is guaranteed to be available during the SigComp session. Otherwise the compressor cannot know when a state has been deleted and must not be used for compression anymore. > I agree with Zhigang that we still need STATE_FREE, > especially because the compressor might not know in advance > (when setting the priority) which states will be the most > disposable ones. Hmm, so what you're after is a way to change the state_retention_priority and not explicitly tell the decompressor that "I'll not use this state anymore" but rather change the priority and let the deletion rule still be as it is. Then I think that this would not be a new instruction but rather an evolvement of the END-MESSAGE instruction. Hmm, such a feature could make it more complicated for a compressor to know what states that are actually established even when explicit acknowledgements are used as described in [extended]. However, I'm not sure how complex it would be it was just a feeling that I got. BR /Hans H > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 06:09:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00909 for ; Fri, 12 Apr 2002 06:09:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04795; Fri, 12 Apr 2002 05:54:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04744 for ; Fri, 12 Apr 2002 05:54:35 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29188 for ; Fri, 12 Apr 2002 05:54:31 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3C9sYs7017754 for ; Fri, 12 Apr 2002 11:54:34 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 12 11:56:19 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Apr 2002 11:44:07 +0200 Message-ID: From: "Jan Christoffersson (EPL)" To: "'Robert.Sugar@nokia.com'" , "'rohc@ietf.org'" Date: Fri, 12 Apr 2002 11:54:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE:[roch] sigcomp issue sugar-5/cabo-8 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi all, some comments on the STATE_FREE discussion: There seems to be no doubt that a STATE_FREE instruction would increase the flexibility of state management, since it would make it possible for the compressor to change the order in which the states are deleted once the state memory is full (perhaps because it realizes that the state about to be deleted is more useful than some other state further back in the deletion queue). The important question is whether this flexibility is important enough to make changes in the draft. From my point of view this depends on how big the state memory is; can it store only three states then a STATE_FREE instruction would be very important. Can it store something like ten or more states then it is not very important. Richard, would it require much changes in the draft to modify the END_MESSAGE instruction to change priority of an already saved state? (I assume this is the way to create a STATE_FREE instruction). From my point of view I would prefer to have this possibility in SigComp. Regards, Jan C. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 07:38:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10096 for ; Fri, 12 Apr 2002 07:38:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07430; Fri, 12 Apr 2002 06:53:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07399 for ; Fri, 12 Apr 2002 06:53:22 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05904 for ; Fri, 12 Apr 2002 06:53:19 -0400 (EDT) From: Robert.Sugar@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3CAsLJ22568 for ; Fri, 12 Apr 2002 13:54:21 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 12 Apr 2002 13:53:20 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 12 Apr 2002 13:53:20 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 13:53:19 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 12 Apr 2002 12:53:18 +0200 Message-ID: <21B200DF0688CC45ACF38F49D2279832063719@buebe002.NOE.Nokia.com> Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8 Thread-Index: AcHiCA24BjRX1bn7RHGJYuT9i5tuvgAA9aHg To: X-OriginalArrivalTime: 12 Apr 2002 10:53:19.0841 (UTC) FILETIME=[420A4D10:01C1E210] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA07400 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit Hi, > > I agree with Zhigang that we still need STATE_FREE, > > especially because the compressor might not know in advance > > (when setting the priority) which states will be the most > > disposable ones. > > Hmm, so what you're after is a way to change the > state_retention_priority and not explicitly tell the > decompressor that "I'll not use this state anymore" but > rather change the priority and let the deletion rule still be > as it is. Then I think that this would not be a new > instruction but rather an evolvement of the END-MESSAGE > instruction. Hmm, such a feature could make it more > complicated for a compressor to know what states that are > actually established even when explicit acknowledgements are > used as described in [extended]. However, I'm not sure how > complex it would be it was just a feeling that I got. Actually to the opposite :). It may have been brought up or even rejected earlier, but I could imagine state deletion like this: Compressor uses the STATE_FREE instruction whenever it thinks the state can be deleted. This way the memory does not have to fill up before removing any states, which would save some resources. As the compressor is aware of the state_memory_size it MUST NOT create a state that he knows it would not fit into the memory and remove some states beforehand. It may have some problem with message reordering and late acknowledgements (the comp. falsely thinks the memory is full/not full), but so does the other solution. In this case a cautious compressor could spare some memory for that purpose, but with automatic deletion the compressor must assume what could have happened at the other side. Correct me if I am wong. From the implementation point of view I feel it is more complicated to mirror the decompressor (even more if we change priorities) than telling it what to do. The effort to be change the draft: New instruction STATE_FREE, possibly removing the automatic state deletion, describing all this. Regards, Robert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 07:49:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11280 for ; Fri, 12 Apr 2002 07:49:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09845; Fri, 12 Apr 2002 07:36:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09765 for ; Fri, 12 Apr 2002 07:34:34 -0400 (EDT) Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09779 for ; Fri, 12 Apr 2002 07:34:28 -0400 (EDT) Received: from ecvwall1.wipro.com (venus.easi.soft.net [164.164.23.6]) by wiproecmx2.wipro.com (8.11.3/8.11.3) with SMTP id g3CAEar14534 for ; Fri, 12 Apr 2002 15:44:36 +0530 (IST) Received: from m2vwall3.wipro.com ([164.164.29.237]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUG9QN00.3QE for ; Fri, 12 Apr 2002 15:43:35 +0530 Received: from 164.164.23.9 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 15:36:34 +0530 Received: from ecvwall1.wipro.com ([164.164.23.6]) by mailstore.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUG9EP00.K3A for ; Fri, 12 Apr 2002 15:36:25 +0530 Received: from wipro.com ([10.113.1.100]) by ggnmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GUG9CA00.41S; Fri, 12 Apr 2002 15:34:58 +0530 Message-ID: <3CB6B106.3B722F59@wipro.com> Date: Fri, 12 Apr 2002 15:33:50 +0530 From: Lalit Bhasin Organization: WIPRO TECHNOLOGY X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lee lik sun , rohc@ietf.org Subject: Re: [rohc] rohc query References: <3CB5549A.DB0DC67D@wipro.com> <001e01c1e1c0$39a88380$0b1510ac@psl.com.sg> Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f21667f2-4df3-11d6-a942-00b0d0d06be8" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org ------=_NextPartTM-000-f21667f2-4df3-11d6-a942-00b0d0d06be8 Content-Type: multipart/alternative; boundary="------------24DBE01EF6B62528DC90ACCA" --------------24DBE01EF6B62528DC90ACCA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lee, Does that means that the outer IP-ID would be sent in uncompressed form even if the IP-ID is showing the sequential behaviour. If this is the case, can't we assume that the outer IP-ID is behaving as random (ie assume that RND2 flag is set) and send it in the ROHC packet after the extension. Thus the extension 3 would not be used everytime in IPv4-Ipv4 tuneeling. Regds, Lalit Bhasin Lee lik sun wrote: > Hi Lalit & all, > > Please correct my understanding if i am wrong. > > IF both RND & RND2 flags are 0. > > encoded IP-ID bits of the inner IPv4 header can sent in the type 0,1 & 2. > But the IP-ID of the outer IPV4 header will have to be sent with an > extension 3 > with the Outer IP header flag (ip2) set and the IP-ID is sent uncompressed > with I2 > of the Outer IP header flag set. > > thanks & regards > LEE lik sun > > ----- Original Message ----- > From: Lalit Bhasin > To: > Sent: Thursday, April 11, 2002 5:17 PM > Subject: [rohc] rohc query > > > hi all, > > In case of IPv4-IPv4 tunneling, if the RND and RND2 flags are 0, > > how is the encoded IP-ID bits of the outer IPv4 header > > sent in the type 0,1 and 2 packets. The base header of these packets > > only carry the encoded IP-ID bits of inner IPv4 header. > > thanks in advance.. > > Lalit > > > > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc -- ******************************* LALIT KUMAR BHASIN WIPRO TECHNOLOGIES GURGAON. Ph. 0124-6398465-69 Ext 2019 9810419594 ******************************** --------------24DBE01EF6B62528DC90ACCA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Lee,
  Does that means that the outer IP-ID would be sent in uncompressed form even if the
IP-ID is showing the sequential behaviour.
If this is the case, can't we assume that the outer IP-ID is behaving as random
(ie assume that RND2 flag is set) and send it in the ROHC packet after the extension. Thus the
extension 3 would not be used everytime in IPv4-Ipv4 tuneeling.
Regds,
Lalit Bhasin
 
 

Lee lik sun wrote:

Hi Lalit & all,

Please correct my understanding if i am wrong.

IF both RND & RND2 flags are 0.

encoded IP-ID bits of the inner IPv4 header can sent in the type 0,1 & 2.
But the IP-ID of the outer IPV4 header will have to be sent with an
extension 3
with the Outer IP header flag (ip2) set and the IP-ID is sent uncompressed
with I2
of the Outer IP header flag set.

thanks & regards
LEE lik sun

----- Original Message -----
From: Lalit Bhasin <lalit.bhasin@wipro.com>
To: <rohc@ietf.org>
Sent: Thursday, April 11, 2002 5:17 PM
Subject: [rohc] rohc query

> hi all,
>       In case of  IPv4-IPv4 tunneling, if the RND and RND2 flags are 0,
> how is the encoded IP-ID bits of the outer IPv4 header
> sent in the type 0,1 and 2 packets. The base header of these packets
> only carry the encoded IP-ID bits of inner IPv4 header.
> thanks in advance..
> Lalit
>
>
>

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc

-- 

*******************************
LALIT KUMAR BHASIN
WIPRO TECHNOLOGIES
GURGAON.
Ph. 0124-6398465-69 Ext 2019
    9810419594
********************************
  --------------24DBE01EF6B62528DC90ACCA-- ------=_NextPartTM-000-f21667f2-4df3-11d6-a942-00b0d0d06be8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-f21667f2-4df3-11d6-a942-00b0d0d06be8-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 09:27:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20683 for ; Fri, 12 Apr 2002 09:27:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14808; Fri, 12 Apr 2002 09:15:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14776 for ; Fri, 12 Apr 2002 09:15:22 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19233 for ; Fri, 12 Apr 2002 09:15:18 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <2V2R4HKS>; Fri, 12 Apr 2002 14:11:42 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFD1@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Hans Hannu (EPL)'" , "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompr ession failure ? Date: Fri, 12 Apr 2002 14:11:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, How about the following solution: 5) A compressor should not reference the same state item more than N times. This prevents a corrupted or lost state from causing more than N SigComp messages to be unsuccessfully decompressed. It's similar to 2) except that there is no need for the compressor to be "application-aware" (i.e. no need for it to detect retransmissions). When SigComp is operating correctly the above restriction has no effect on the compression ratio, because states are not normally referenced by more than one SigComp message. The solution only has an effect when the compressor does not receive acknowledgements for a long period of time (in which case it may continue to reference the same state item in many SigComp messages). In this case it is prudent to stop referencing the state after a while, just in case the state is lost or corrupt. As Hans mentions, this is an implementation choice at the compressor and something that we should consider for the implementer's guide. Regards, Richard > -----Original Message----- > From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > Sent: Friday, April 12, 2002 9:17 AM > To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org > Subject: [rohc] RE: sigcomp issue zliu-3: cannot recovery from > decompression fail ure ? > > > > how does > > SigComp recover from a decompression failure caused by > > reference to a corrupted or lost states (e.g. due to system > > failure at decompressor)? > > > > The problem is that the decompressor cannot send NACK to the > > sending compressor indicating such a failure because it > > does not know to whom it should send the NACK. The endpoint ID > > that sent a SigComp message can only be derived *after* > > the message is successfully decompressed due to security > > reasons. A potential deadlock? > > I would say that the potential deadlock depends on how your > implementation behaves. > > > Possible answers: > > 1) Let's forget about it as it rarely happens. > > It is probably true that it rarely happens, but one (at least > the implementer) should not forget about it. > > > 2) The application will resend the message. The compressor > > can detect this and assume it is caused by decompression > > failure and fallback to no state for compression of this > > and subsequent message. > > This seems like a solutions that would work. > > > However, this failure could be > > caused by message loss or corruption. > > True. > > > Then the compression > > efficiency is unnecessarily sacrificed. > > A compressor implementation would have to weigh the > possibilities that the message is resent due to decompression > failure, message loss or corruption. Then it should decide in > which form it should resend the message; compressed, > uncompressed, "restarting" compressed message. > > > 3) Find a way to enable NACK if possible at all. > > This seems to be hard because of the security reasons. > > > 4) Let's forget about it as it is unsolvable. > > You could use 2) above. > > > I have no good idea and would like to hear opinions from the WG. > > Well, I think that 2) do sounds like a good idea. In my > opinion that would not be a standardization issue for the > ROHC WG, but rather an implementation issue -> "implementers guide". > > BR, > /Hans H > > > BR, > > Zhigang > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 15:05:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00736 for ; Fri, 12 Apr 2002 15:04:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04691; Fri, 12 Apr 2002 14:49:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04663 for ; Fri, 12 Apr 2002 14:49:47 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00277 for ; Fri, 12 Apr 2002 14:49:44 -0400 (EDT) Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3CInLa21161; Fri, 12 Apr 2002 20:49:22 +0200 (MEST) Message-ID: <3CB72C39.506@tzi.org> Date: Fri, 12 Apr 2002 20:49:29 +0200 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lalit Bhasin CC: rohc@ietf.org Subject: Re: [rohc] segmentation issue.... References: <3CB68607.84F187D4@wipro.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit Lalit Bhasin wrote: > hi all, > As per RFC 3095 Section 5.2.5.2 SEGMENTATION PROTOCOL, the Segment > header doesn't carry a CID. > In the same section, later it is written that the CID is derived from > the initial octets of the reconstructed unit. These two > statements are contradicting each other. It is not clear that why the > CID should not be a part of the Segment header. Hi Lalit, the idea is that the segmentation header itself does not have a CID. So all the tiny segments being put together to one reconstructed unit do not carry a CID. Then, the reconstructed unit is treated like a ROHC packet, and can carry a CID. No contradiction. (If you look at the bits on the wire, most likely the CID will be in the *segment* of the first packet -- not in the segmentation header, and not in any other packets contributing to the reconstructed unit.) > Information contained in this E-MAIL being proprietary to Wipro Limited > is 'privileged' and 'confidential' No. This is a submission to an IETF mailing list, so you submit to the IETF rules. (I know I'm picky today, but this has to be stressed occasionally.) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 15:13:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00988 for ; Fri, 12 Apr 2002 15:13:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02768; Fri, 12 Apr 2002 14:17:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02736 for ; Fri, 12 Apr 2002 14:17:11 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29008 for ; Fri, 12 Apr 2002 14:17:08 -0400 (EDT) Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3CIGva17021; Fri, 12 Apr 2002 20:17:01 +0200 (MEST) Message-ID: <3CB724A0.4010100@tzi.org> Date: Fri, 12 Apr 2002 20:17:04 +0200 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Price, Richard" CC: "'Hans Hannu (EPL)'" , "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: Re: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompr ession failure ? References: <76C92FBBFB58D411AE760090271ED41804A0EFD1@rsys002a.roke.co.uk> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 7bit > 5) A compressor should not reference the same state item more > than N times. I'm not sure there's a good N. If we are going down this path, I'd rather see a time limit, because it's recovery time that really is going to influence the user experience. > When SigComp is operating correctly the above restriction has > no effect on the compression ratio, because states are not > normally referenced by more than one SigComp message. I'm not sure that's true for the simplest implicit ACK case. > As Hans mentions, this is an implementation choice at the > compressor and something that we should consider for the > implementer's guide. Right -- this should be documented as one of many ways to handle the problem. Certainly not a normative thing. I believe we should stress in the document that sigcomp works best if there is fate-sharing between the compression state and the application state. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 16:26:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03183 for ; Fri, 12 Apr 2002 16:26:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10525; Fri, 12 Apr 2002 16:20:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10496 for ; Fri, 12 Apr 2002 16:20:10 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02903 for ; Fri, 12 Apr 2002 16:20:06 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3CKJGu00417 for ; Fri, 12 Apr 2002 23:19:17 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Apr 2002 23:20:07 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 12 Apr 2002 23:20:07 +0300 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 12 Apr 2002 15:19:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE:[roch] sigcomp issue sugar-5/cabo-8 Date: Fri, 12 Apr 2002 15:19:51 -0500 Message-ID: Thread-Topic: [rohc] RE:[roch] sigcomp issue sugar-5/cabo-8 Thread-Index: AcHiCCJkJQ1fILiCSQ2RosAXBj6MOgAVCRPw To: , , X-OriginalArrivalTime: 12 Apr 2002 20:19:52.0174 (UTC) FILETIME=[670CB0E0:01C1E25F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA10499 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit > From my point > of view this depends on how big the state memory is; can it > store only three states then a STATE_FREE instruction would > be very important. Can it store something like ten or more > states then it is not very important. Then that seems to say we need STATE_FREE at least for the first case (e.g. for some low end terminals). > Richard, would it require much changes in the draft to modify > the END_MESSAGE instruction to change priority of an already > saved state? (I assume this is the way to create a STATE_FREE > instruction). Sorry, I don't get it. STATE_FREE instruction has nothing to do with priority (how it is used together with priority is another issue). It simply says "I'm not going to use this state anymore". The receiver of the instruction doesn't even look at the priority at all. What does it buy us to change the state priority to the lowest value and then delete it instead of a straightforward STATE_FREE instruction? Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 17:14:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04419 for ; Fri, 12 Apr 2002 17:14:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14117; Fri, 12 Apr 2002 17:09:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14082 for ; Fri, 12 Apr 2002 17:09:39 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04338 for ; Fri, 12 Apr 2002 17:09:35 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3CL9m515502 for ; Sat, 13 Apr 2002 00:09:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Apr 2002 00:09:32 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 13 Apr 2002 00:09:32 +0300 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 12 Apr 2002 16:09:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8 Date: Fri, 12 Apr 2002 16:09:23 -0500 Message-ID: Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8 Thread-Index: AcHiCCLIxWLM26jZQhi8xBTZ352nQQAV1pqg To: , , X-OriginalArrivalTime: 12 Apr 2002 21:09:23.0810 (UTC) FILETIME=[52485C20:01C1E266] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA14083 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Content-Transfer-Encoding: 8bit > Hmm, so what you're after is a way to change the > state_retention_priority and not explicitly tell the > decompressor that "I'll not use this state anymore" but > rather change the priority and let the deletion rule still be > as it is. Hans, Sorry, I wasn't clear. What I described is one example to use STATE_FREE instruction. STATE_FREE does mean that "I'll not use this state anymore". This is independent of state priority. Robert already explained it pretty well: "This way the memory does not have to fill up before removing any states". The point is that there is something a compressor can do with STATE_FREE, but not with priority. Of course, a compressor can feel free to consume all the memory allocated to it. But on the other hand, we should give it a chance to be nicer (to the receiving sigcomp) if it wants to. One additional point: I don't think priority approach and STATE_FREE is mutual exclusive. And I don't think they have to be bundled together. Both have their own merit and we should give implementer the freedom. Having said good words on STATE_FREE, the priority approach may be more efficient since you can use small amount of bits (for priority) per message to control the deletion. That can also be done via STATE_FREE, but in a trickier way. E.g. you refer to one state (cost you >= 6 bytes) that contains hash values of other states; then in the sigcomp message, you only need to send a few bits to tell which one of the states you want to apply STATE_FREE. This avoids sending additional state_ID in the message, but needs a bit more complicated UDVM code. Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 17:21:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04515 for ; Fri, 12 Apr 2002 17:21:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14431; Fri, 12 Apr 2002 17:17:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20956 for ; Fri, 12 Apr 2002 11:03:39 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03635 for ; Fri, 12 Apr 2002 11:03:34 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3CF3a3G017054 for ; Fri, 12 Apr 2002 17:03:36 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Apr 12 17:03:24 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Apr 2002 16:53:00 +0200 Message-ID: From: "Krister Svanbro (EPL)" To: "'rohc@ietf.org'" Date: Fri, 12 Apr 2002 17:01:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Finalization of SigComp Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hi all SigComp-friends, I believe that it was stated at IETF53 in Minneaplois that a new set of drafts were to be submitted on April 5th and that these drafts should be the basis for a SigComp WG last call. This has apparently not happened. From what I understand it is two minor issues on UDWM instructions that is causing the delays. Looking at the full scope of SigComp it also seems as these two issues are not critical or core parts of SigComp. Given that I would like to encourage all involved to work as swiftly as possible to find closure for these minor issues as soon as possible. If we cannot do this we make it impossible for IESG and IETF to meet the expectations i.e. 3GPP have on a signaling compression solution. Looking forward to new drafts to review in a WG last call beginning of next week. BR, / Krister Svanbro _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 18:30:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05528 for ; Fri, 12 Apr 2002 18:30:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17647; Fri, 12 Apr 2002 18:23:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17557 for ; Fri, 12 Apr 2002 18:22:10 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05471 for ; Fri, 12 Apr 2002 18:22:04 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3CMM73G007425 for ; Sat, 13 Apr 2002 00:22:07 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Apr 13 00:22:06 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTJ2N9>; Sat, 13 Apr 2002 00:22:06 +0200 Message-ID: From: "Lars-Erik Jonsson (EPL)" To: "'rohc@ietf.org'" Date: Sat, 13 Apr 2002 00:21:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] ROHC Minutes, IETF 53 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Minutes of the ROHC WG sessions at IETF 53 ========================================== Hilton and Towers Hotel, Minneapolis,MN Tuesday morning and afternoon, 2002-03-19 Reported by: Lars-Erik Jonsson Note takers: Christian Schmidt, Hans Hannu, Mark West and Jonathan Rosenberg Slides are available at http://www.dmn.tzi.org/ietf/rohc Morning session, 0900-1130 -------------------------- * WG admonishments (Bormann) Carsten reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. People are encouraged to read RFC 2026 and RFC 2418, which define our processes. We are here to make the internet work, and we use rough consensus and running code instead of voting. The ROHC WG is chaired by Lars-Erik Jonsson and Carsten Bormann, with support from our area directors, Allison Mankin and Scott Bradner. Note that the real work is done on the mailing list, although face-to- face meetings can sometimes help the progress. Finally, Carsten stressed the RFC 2026 IPR policy, which says that any contribution must identify whether the contributor(s) is(are) aware of any IPR issues related to the contribution. * Agenda bashing (Bormann) Carsten presented the proposed agenda, which was accepted without modifications. * WG status (Jonsson) Lars-Erik reviewed WG goals and milestones. The RTP part is done, while most of the other work is started, although we do not yet have WG documents for all items (SCTP profile, UDP-Lite profiles, and LLA implementation examples are so far only discussed in individual Internet Drafts). SigComp was due in January, according to the milestones, and is thus late. However, the work is now progressing quickly, and should soon be finalized. The SigComp security evaluation, currently listed as a separate WG document, will go into the base SigComp document. Finally, the preparation for RFC 3095 draft standard has not yet started. * Document status (Jonsson) RFC 3095 and RFC 3096 are the only WG RFC's published, so far. Three more documents, "ROHC over PPP", "0-byte requirements", and "LLA RTP profile", have been approved and are currently in the RFC-editor's queue. Two documents, "RTP lower layer guidelines", and "LLA RTP R-mode", have been submitted to the IESG, passed IETF last-call, and are now awaiting IESG approval. Drafts: draft-ietf-rohc-over-ppp-04.txt draft-ietf-rohc-rtp-0-byte-requirements-02.txt draft-ietf-rohc-rtp-lla-03.txt draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt draft-ietf-rohc-rtp-lla-r-mode-02.txt * New mailing list (Jonsson) The ROHC mailing list had lots of spam, and in the process of taking actions against that, it was decided to move the list to "ietf.org". The old list, rohc@cdt.luth.se, is now closed, and all subscribers have been moved to the new list, rohc@ietf.org. The new list is subscriber-post, with other messages moderated by Lars-Erik, who checks incoming mails and filter Spam. This was applauded by the working group! * Signaling compression - Introduction (Bormann) Carsten reported that there had been an ad-hoc meeting on Sunday evening with SigComp authors, ROHC chairs, and various 3GPP people. The intention with that meeting was to exchange information, and make sure we have not missed anything or made assumptions that are not valid. The material presented there has been updated with inputs from that meeting, and will be the basis for the following meeting discussions at this session. We are doing this work mainly to minimize connection setup delay, and that is different from previous work, which was motivated by bandwidth saving needs. To deal with middle call interrupts is a secondary goal. Focus is on compression of SIP and SDP, but the solution should be generic so that it can be used for e.g. RTSP, and possibly also for DNS and RSVP. Details may of course be different when considering new protocols. Motivations and objectives for the work are discussed in the requirements document. When we started to look at this issue, we found that it would not be a simple task to choose a compression algorithm, since there are hundreds of them and they are all different. To select one or two standard algorithms had been one way, but especially IPR issues would make that a hard thing to do. Therefore, we started to look at the possibilities to let the compressor completely control the decompressor. We have designed a universal decompressor virtual machine (UDVM), which gets an executable decompressor uploaded from the compressor. There are therefore no compression schemes in the standard and any compression algorithm can be implemented by a compressor. The UDVM can be visualized in two ways - like an adaptive version of Deflate, or like a Java virtual machine, but much simpler and optimized for compression. The available instruction set is designed for its specific purpose, and selected for minimum code size. Simple algorithms would require about 50-70 bytes, while more complex ones gets slightly bigger. In general, an algorithm should require 50-200 bytes to be uploaded from compressor to UDVM. - Overview (Bormann) SigComp has been envisioned as a shim layer between the application layer and the transport layer. However, although this is where it is located in the architecture, to call it a shim layer might not be quite correct, since the interface from SigComp towards the application is more complicated than with a normal shim. Anyway, it is independent from the underlying transport protocol, and therefore supports arbitrary transports, such as per packet compression for e.g. UDP, and per-stream compression for e.g. TCP. Compression is either done per-message, or by using state references, and the decompression algorithm to use is either uploaded by the compressor, or an already present one is referenced. Since stateless, per-message, compression is not as efficient as dynamic compression, it is beneficial if previously established state can be referenced for improved compression. There are several ways to know which states have been established at the decompressor. A compressor can utilize application knowledge, usually referred to as implicit acknowledgements, or rely on explicit acknowledgements, state announcements, sent from the decompressor for each state established. Further compressed messages can then refer to these established states. A compressor can thus itself decide if dynamic compression should be implemented, and in such case also which mechanisms for dynamic compression to use, which seems to be a useful flexibility since there is potential IPR concerns with these mechanisms. For various reasons, including security aspects, state identifiers are cryptographic hashes over the state information. To reference a state, the compressor thus needs to be able to build a crypto hash over the state, which is equivalent to saying the state must be known by the compressor. Further, state must never be saved by a decompressor without permission from the application to do so. The UDVM approach with possible state references means that there is no need to negotiate anything. A sender must know that the other end supports compression, but the rest of the information used to optimize things comes in the ways of announcements of additional capabilities, and/or available states. One end can tell the other end that it has the Deflate algorithm, and that would be done with a state announcement. It should be noted that the usefulness of such state announcements is questionable, since it is very efficient to upload an algorithm. As an example, Deflate requires about 66 bytes to be uploaded, so considering also the additional rtt required for announcements, announcements may cost more bandwidth than what they can save. The initial compression ratio can be significantly improved with a mandatory, application-specific, state. Such a mandatory static dictionary should be defined, initially for sip. This predefined sip dictionary would be selected and basically fixed forever, otherwise we would be back to the negotiation issue. Note however that this is an application specific item, and outside of scope for the SigComp protocol. It had been suggested to do this work within the sipping wg, with a small design team of sip, rohc, and 3GPP aware participants. Goal should be a small but useful and reasonably future-proof dictionary for sip/sdp. - SigComp documents (Bormann) Currently, we have five WG SigComp documents available from the ID archives, but two of them, sigcomp-udvm and SigComp-algorithm are old. Requirements are in draft-ietf-rohc-signaling-req-assump. The base SigComp document is now draft-ietf-rohc-SigComp, which defines framework and UDVM, transport plus per-message compression. A second document, draft-ietf-rohc-sigcomp-extended, describes in more detail how to implement enhanced mechanisms, such as stateful compression based on sharing and reusing state in each direction. This latter document is informative, since implementation is done in the compressor only, so the material has been kept out of the base SigComp. Also, there are known IPR concerns with these enhanced implementation mechanisms, so it is nice to have it in a separate document. In this way, we get a basic solution which is, to our knowledge, IPR free, and an enhanced version which has known IPR claims, especially covering implicit and explicit acks. Note that although we are currently not aware of any IPR on the base solution, we can not know if there are IPR's anyway. The extended operations is only informative, but we need to finish it together with the baseline SigComp, to make sure the base specification has everything to make the extended operations implementable. A forth document is planned, but does not yet exist as an Internet Draft. The document is intended to be an informative user guide, making life easier for implementers of SigComp. There are already many ideas for what should be in this document. One is an assembly language for interchanging UDVM code. It could further include some example decompressors, such as lz77 simple, deflate, lqx, etc. Other items that have been brought up as potential content for this document are text on what needs to be done to put SigComp in a new environment, for RTSP guys when they come along, and various hints for UDVM implementors. There have been many good mails on the list regarding efficiency, and these should be captured. Drafts: draft-ietf-rohc-signaling-req-assump-02.txt draft-ietf-rohc-sigcomp-05.txt draft-ietf-rohc-sigcomp-extended-02.txt - SigComp architecture issues (Bormann) Four different, but to some extent related, architectural SigComp issues have been under discussion, and are more or less solved. 1) Discovery vs. SigComp 2) Multiplexing (compressed vs. Uncompressed) 3) Integration into an application protocol 4) What is needed to interface with an application (1) SigComp discovery The issue of how to invoke the SigComp shim, including how to discover that the other end supports SigComp and how to indicate that messages are compressed, has been discussed several times before. We started out waving our hands, and the issue has been "solved" many times. However, this turns out to be much harder than we have thought. We must find a solution that fits into the existing application discovery architecture, this is not only about SigComp. The old tricks may not work that well anymore. We used to overload schemes, http port 80 became overloaded by https by assigning a new port 443. Different ports have been used for different things, but we are now running into a combinatorial explosion, and there are many things you may want to do. There might be many versions of both security and compression, and other shim layers may turn up. Since there is only 2^16 ports, one can not get a port for each, so a new architecture is thus needed, says the IESG. We cannot go ahead with a scheme that tries to perpetuate this. This is hard, and there really are no pre-cooked answers. For the immediate pressing issue, SigComp in 3GPP release 5, this should not be a big issue, since they have discovery for pcscf already, and it should be quite easy to put SigComp in there as another item to discover. To get done in time for 3GPP, and since the general issue is hard to solve, the proposal is to not at all solve the discovery issue in SigComp. Keith Drage pointed out that in 3GPP, both UE and proxy will simply have to support it, and thus its not even needed in discovery. Carsten responded that using 0 bit discovery is ok, thus mandating SigComp. Lars-Erik pointed out that it still does not mean the use of SigComp is mandated in 3GPP, only the support for it in all entities. (2) Multiplexing mechanisms When leaving discovery out of SigComp, and especially when it might be avoided by making SigComp support mandatory in certain environments, we need a way to distinguish compressed messages from uncompressed messages, which works independent of whether external multiplexing mechanisms are present or not. Current text says you can use different ports, but that assumes an external mechanism we can not expect to have available. We have therefore discussed to make SigComp messages self-describing. So, if there is no port or other external multiplexing mechanism, one can look at the message itself and figure out if it is a compressed message or not. It has been proposed to use the initial 5 bits for this, with 11111xxx for SigComp compressed messages. Ascii start with zero, and this also works for utf-8. Further, it will make sure underlying RTP rohc can distinguish SigComp messages from RTP when initiating compression profile (10xxxxxx is normally treated as potential RTP). The proposal is thus to provide the above multiplexing mechanism within SigComp, but also allow other external mechanisms to be used, such as port multiplexing, since its related to discovery. (3) Integration into an application protocol SigComp currently has a number of application dependent parameters, to be defined for each application of SigComp, e.g. for SIP over SigComp. However, we expect to be able to reduce the number of parameters significantly by coupling them together, and/or by defining default values or default minimal values for them on a general SigComp level. If there are any parameters left after that, we must now at least define values for them for the SIP case. More discussions on this followed when the UDVM was discussed. One application-specific parameter that we should define for the combination of SIP and SDP is a static dictionary, since that would significantly improve the compression efficiency, at least for the initial messages. However, this should really be static, and must not be changed every week. It should thus be about as static as port numbers. Although the compression efficiency might deteriorate over time as new things are added, this should be a negligible problem. Questions were raised about various upcoming or future additions that we might want to include. Carsten responded that if sip uses FLOP in two years, we should add that now. But, we do want to keep the dictionary small. If it is too large, we would increase minimum size of certain parameters. When talking about 2kb UDVM implementations and a 1500 byte mtu, dictionary more than 1500 bytes would be a problem. Jonathan Rosenberg proposed to have dynamic dictionaries, but that is still possible to have in addition to the static dictionary. The point with a static dictionary is that it does not have to be uploaded over the air, and it can be used immediately, without any announcement. Carsten concluded that we will build a design team to define a static dictionary for SIP/SDP, and the AD's have suggested to do this within the Sipping WG. Richard and Carsten will participate from the ROHC side, and we will figure out who to get from the sip/sdp side. (4) Interfacing the application The state management assumes that for each incoming message with state creation, the application will be able to tell if message had enough merits to allow creation of state. This implies a stronger coupling between application and compression than we initially had envisioned, and it gets worse. When the application allows a state to be saved, it must provide an endpoint identifier for the sender of the message, which can be used by the SigComp entities to control state memory allocations. How to find unique identifiers is a difficult issue, although it is outside the scope of SigComp itself. Further discussions were deferred to the mailing list. - Timeline and document dependencies (Bormann) 3GPP is urgently waiting for this work to finalized, so important questions are when we expect to be done and which document dependencies we have. Although it is only informational, the extended operations document must be available at same time as base draft, since that is the only way to verify completeness of the base draft. The requirements document should also be simultaneously published. but the user guide will wait for various reasons. First of all, it is not yet started, further it will benefit from more implementation experience and become more useful when more complete, but will take some time to grow. As an informative document, it will also be useful already while its an Internet Draft, since there is no need for last call before you can use it. It is thus ok to leave it for much later, and have it live as a Internet Draft for a while. The authors believe we can have an updated (-06) version of SigComp on April 5, along with an updated (-03) version of the extended operations document. Hopefully, the documents are then ready for WG last call. Keith asked when this means we can see a last call, and Carsten deferred that question to Lars-Erik's summary of the procedural issues, to follow in the end of the SigComp session. - The universal decompressor and the state handler (Price) Richard went through the changes since Salt Lake City, and the open issues identified on the base SigComp draft. Basic SigComp is really about three things, the compressor, the decompressor (UDVM), and state handling. The compressor basically does not need to be covered, since its implementation is a local decision. Simple compression algorithms can be programmed directly, while more complex ones would require a compiler to generate the byte code, to be uploaded to the decompressor (UDVM). Byte code compilers may be subject to IPR, as well as the algorithms themselves might be. News in SigComp -05 were then discussed. Variable length encoding for operands has been added, and this resulted in a reduction on the byte code size, e.g. from 96 to 47 for lz77, and from 132 to 66 for lzw. The ability to decompress stream data has also been added, and a number of new UDVM instructions have been included, such as instructions for saving and retrieving state, for bit manipulations, and for initialization. To simply the scheme, it would be desirable to fix several of the application dependent parameters currently listed, and there is probably no need to specify most of those on a per-application basis. Richard suggested to remove the max-expansion-size parameter, since the first message might possibly be expanded a lot. The buffer- size and udvm-memory-size parameters are correlated, and the minimum values for compressed and uncompressed data should be based on the udvm-memory-size parameter, which will then be the only of those parameters left. Further, we should remove minimum-hash-size, and make it be a decision made by the compressor. Cycles-per-message could also be removed by fixing it to 1000 for all SigComp usages. Carsten suggested to change some fields in the decompressor announcements so that maximum-state-size could be announced. In case an endpoint can not save state, it would announce it is stateless. The cycles-per-message parameter should also be fixed for SigComp. Further, Richard wondered whether any UDVM instructions should be added. Carsten proposed to add SHIFT and MODULO, since if we do not do it now, it will never happen. Jonathan pointed out that the UDVM could be upgraded later, but it was agreed that upgrading the UDVM is undesirable since it requires announcements of enhanced versions. It would thus be great if we could include full instruction set already in the initial version of the UDVM. Richard asked if more CRC's should be added, and Carsten proposed to add a UDVM parameter for the CRC polynomial. Finally, it was discussed how many values there should be for UDVM parameters. The proposal was to fix e.g. six or seven values for UDVM memory size, which was also agreed. Overall, the impression was that the open UDVM issues are minor, so we could consider that part as more or less finished. The second part covered by Richard was the state handler, which is a new functionality added after the Salt Lake City meeting. State can be saved, but only with permission from the application. State is saved and referenced using a hash, so a malicious user cannot access state without knowing it. It was proposed to make state identifiers flexible in size when referencing them. A decompressor would always save them as 16 byte hashes, but a compressor could choose to reference with any size between 6 and 12 bytes, depending on collision probability. Currently there is a minor problem with the acknowledgement schemes defined in the extended operations document, which are caused by the way the base SigComp/UDVM works. The problem is that if e.g. sip messages are used as implicit acknowledgements, it is the compressor that decides to initiate it, but with explicit acknowledgements, the decompressor decides. This can be solved by letting the compressor initiate also explicit acknowledgements by combining appropriate UDVM instructions, and such a solution should be possible to allow for in the base SigComp without stepping on any known IPR. There were therefore no objections to do so. Some additional issues were then discussed. The first one was whether it should be possible for the compressor to choose which hash to use. UDVM instructions could be provided for md5 and sha1, and since there seems to be no security risks with that approach, this was agreed to be a useful feature. The rest of the discussions were about state creation, state deletion and priorities for states. There were some questions on whether state-free can be made secure, and Jonathan suggested to keep things simple and leave things out that are not obviously needed. Carsten responded that we have done a lot of trimming from -04 to -05, and that was the major difference between the two versions. It was then agreed to add the above mechanisms for state control. - SigComp extended operations (Hannu) Hans Hannu gave a quick update and status presentation for the SigComp extended operations document, which is an informational document describing how various enhancements can be implemented based on the mechanisms provided by the basic SigComp and the UDVM. This material has been placed in a separate document because it is pure informal, describing special implementation tricks, but also because there seems to be potential IPR's associated with these implementation tricks. The most important mechanisms described in the document are explicit acknowledgements, which enables dynamic compression based on previously compressed messages, shared compression, making it possible to share compression states between compressor and decompressor, and state management methods, such as state rollback. Since Salt Lake City, the document has been synchronized with the SigComp document, and they do now fit together. An architectural description of explicit acking has been included, and some additional mechanisms have been added. Since the current draft was announced, some modifications have been agreed, such as the way explicit acking is enabled, which now does not require extensions to the announcement format of SigComp. The code for enabling these mechanisms are now fully controlled by the compressor. The open issues with this document were previously discussed as UDVM issues, since most of them relates to which instructions are needed to implement these mechanisms. UDVM byte code for implementing extended operations was shown, and is rather short, although it has not yet been fully verified. - Security aspects (Bormann) Carsten gave a presentation on the security concerns with SigComp, and how these issues have been addressed. The security goals are simply to not create any new risks, worsen security of existing application protocols, or hinder deployment of application security. For confidentiality, i.e. snooping into state of ther users, the use of cryptographic hashes as state identifiers with a minimum length of 6 bytes is expected to provide a sufficient protection. Longer identifiers of up to 12 bytes are recommended, depending on the risk of state collision for each specific environment. Snooping of state identifiers should not at all be a problem, since one could not get any more knowledge from that than by looking at the message itself. For integrity of messages, SigComp itself will not help, but might jeopardize it. An obvious attack would be to fake state or make unauthorized changes to state. However, state can not be destroyed or changed by a malicious sender, it can only add new state. Fake state should only be a problem if memory limitations would cause losses from FIFO, making this a DoS problem rather than an integrity problem, and we rely on endpoint identifications provided by the application to avoid this. When considering other DoS attacks, there are a number of aspects to consider. SigComp only generates one decompressed message for each incoming message, so the usage of SigComp does not change the vulnerability of the application in that regard. SigComp could potentially make messages larger and an attacker could then send small packets that are decompressed to large ones, which is a risk the application must be aware of. Considering attacks on SigComp itself, the obvious attack would be to fill it with state, but that can only be done with consent of the application. SigComp should therefore not add any such vulnerabilities, compared to those present for the application itself. Finally, another potential attack on SigComp itself would be to send messages with "looping code". To avoid this, we will define an upper limit for the number of "CPU cycles" that can be used, e.g. 4 cycles per bit plus 1000 cycles per compressed message. The problem would still be there, but be limited, and this is true for any decompressor that can receive packets from anywhere. Carsten concluded that we are in rather good shape regarding the security aspects. We have gotten special competence involved to look at this, and no missing pieces have been identified so far. - Implementation status (Bormann) Carsten reported that there are currently three implementations in progress at Dynamicsoft, Roke Manor Research, and TZI: (www.dmn.tzi.org/ietf/rohc/UDVM). The assembler is 205 lines, and the UDVM currently about 520 lines of perl code (estimated to be around 750 lines when completed). Implementers have started to interchange code, to verify correct decompresses, which so far has been successfully done for lz77, deflate, and lzw. What has not been done so far is testing of state management interoperability, and testing in real setting. This is still just the start of the story. However, the UDVM seems to work and it is worth the effort. Carsten's perl implementations, although not complete, were written within one day. - What now? (Jonsson) Lars-Erik summarized the status based on previous discussions and issues raised. Discovery is left outside of SigComp, and we only provide methods to multiplex compressed and non-compressed messages. In 3G systems, that should be enough for now if they mandate support for SigComp. The discussion of a static dictionary for SigComp concluded that this will be defined for SIP in a cooperation between ROHC and SIPPING, and will be done quickly to meet the 3GPP release 5 together with SigComp. However, this is independent of SigComp itself and does not affect our progress in ROHC. To summarize, there seems to be only cosmetic discussions left for the UDVM, the security issues have all been addressed and we do have running code. If all issues raised on the list can be tracked, solutions provided and agreed, and updated drafts submitted on April 5th, it would potentially be possible to issue a WG last-call for these documents on April 8th. This would be a normal 2-week WG last-call, which, if successful, would be followed by the normal IESG process, including a 2-week IETF last-call. Afternoon session, 1545-1800 ---------------------------- * Role of EPIC-Lite in the ROHC work - Architectural role and naming (Jonsson) Lars-Erik summarized previous conclusions and agreements about what EPIC is. As pointed out by Mark West in his Salt Lake City presentation, EPIC is not a complete compression scheme, but a compressed header format generator, making it possible to avoid the hard work of creating the compressed header formats by hand. We have previously agreed to look at EPIC for this purpose, but it has not been completely clear exactly how to use it in the WG, or how it would fit together with the ROHC framework. The intention is now to not only summarize the current status, but also to outline a way forward with this work. - A simple RTP profile example (West) As suggested in Salt Lake City, an EPIC-based RTP profile has been defined to provide an understandable example. This way, we might get a better understanding of EPIC Lite, and even of the TCP-work. This is not a complete solution, only a limited example, but it does define mechanisms such as CSRC-list compression, for comparison with the RFC 3095 RTP profile. The profile is not compatible with the one in RFC3095, but provides similar performance. With this profile, it has been shown that it is possible to write an RTP profile based on the EPIC tools, which is essentially equal to ROHC RTP. This is useful for further discussions, and to tune the tradeoff between efficiency and complexity. Draft: draft-surtees-rtp-epic-00.txt - EPIC-Lite, news & open issues (West) Mark gave a quick update on the EPIC-Lite draft. The core concept, definition and pseudo code are stable, and there are now more than one implementation coming up. One important issue that is currently being addressed is the complexity of profiles, and also they are trying to get the whole thing more easy to understand through an improved structure and comments in the pseudo code. One thing that should be removed is the stack manipulation approach, which is a little bit strange, and unnecessary complicated. Draft: draft-ietf-rohc-epic-lite-01.txt - Way forward (Jonsson) Lars-Erik finally summarized the EPIC issues on a high level, explained how the chairs see this as part of the ROHC work, and outlined their proposal for how to progress. There have not been much discussion about EPIC on the mailing list, and there seem to be difficult for people to get involved, which is an essential key to be able to go further. To both simplify discussions and clarify how this fits into the ROHC work, we should take it into pieces, since there are more than one component in this. It is a tool for compressed header format generation in profile standardization, but it consists of at least two parts. First, it has a generic notation language to describe the header fields that are compressed, and how to compress each fields. Secondly, there are one or several encoding methods that can be used to generate the actual compressed header formats. Any such encoding would take as input the compression description for a profile, based on the generic notation language, and generate compressed header formats, which would differ depending on the encoding method used. The proposal is to write a new working group document, covering only the generic notation language. This is completely independent of the encodings, and should for completeness be evolved concurrent with various profile standardizations. Mark West has agreed to serve as editor for this document, and we should be able to see a first embryo within about one month. Encoding methods should be discussed first later on. In the end, this will give us a toolbox to use when we standardize future ROHC profiles. Qian asked whether this might delay the TCP work, or if we should reconsider using this toolbox for the TCP profile. Lars-Erik responded that we are not really in any urgent hurry to finalize the TCP profile, and Carsten further pointed out that this might instead accelerate the progress, since we can now focus on each separate part, and only the notation is relevant for the profile work. Further, if we get this tool right, we would simplify the profile development work by avoiding hand-made compressed header formats, which would be much more complicated for TCP than it was for RTP. * TCP profile - Requirements and field behavior (West) Mark gave a quick review of the TCP requirements and field behavior documents. Requirements are rather stable and will finally be called for freeze. As usual, we will keep the requirements in the WG until we have a solution ready. The field behavior draft, currently an individual draft, will be re-submitted as a WG document when the internet-drafts open after Minneapolis. Also the behavior document seems to be stable, although it would probably benefit from more review by TCP experts. Drafts: draft-ietf-rohc-tcp-requirements-03.txt draft-west-tcpip-field-behavior-01.txt - News & open issues (Qian) Lately, there have been some constructive discussions about the TCP profile on the mail list. Qian summarized the outcome from those discussions, of which the most important conclusion probably is to make the window estimation an implementation issue only, and not build the TCP profile on it. When talking about modes for TCP, Lars-Erik asked whether there are different packet formats for U and B modes. Qian answered that this is currently the case, because the Master Sequence Number (MSN) not needed in both modes. Lars-Erik explained that this means we need four-way handshakes as in the RTP profile, and expressed concerns about this unnecessary complexity of mode transitions. It was agreed to use the same formats U and B mode to keep the uni-/bi-directionality aspects as simple as possible. Currently, there is a non-official draft update for the TCP profile circulating out there. Lars-Erik asked Qian to submit the draft now without editing, to avoid confusion of which draft that is "valid". Then we should be able to continue the work. Draft: draft-ietf-rohc-tcp-00.txt * SCTP profile - Requirements, news & open issues (Schmidt) Christian gave a short update on the SCTP compression requirements, but there have been no major changes. Lars-Erik asked whether there had been any comments on the list, but unfortunately not. People are therefore encouraged to send comments to the list, if they are interested in SCTP compression. Lars-Erik further pointed out that the requirements will stay in the WG until we have a scheme ready, and we can not consider it ready either, without more discussions and comments. Draft: draft-ietf-rohc-sctp-requirements-00.txt - A first profile attempt (West) Mark continued with a few words about his first SCTP profile attempt. It is a starting point, showing that it is possible to compress SCTP, but currently not much more. Lars-Erik asked if he had any ideas how much we could potentially reuse from TCP when we do SCTP. Mark answered that he has not yet looked at that, but most likely there will be at least something that can be reused. However, SCTP has quite a different structure than TCP and RTP, so there is probably a need to invent some completely new mechanisms. Carsten finally asked if anyone in the room cares about SCTP compression? The audience answered with silence. Draft: draft-west-sctp-epic-00.txt * RTP issues - Implementation & impl. guide (Jonsson) The implementers guide for ROHC RTP has been updated with new stuff, corrections, and improved clarifications. The improved procedure for mode transitions has been corrected, and is also both better described and motivated. Further has it been clarified what is initially needed before mode transition (to O or R mode) can be initiated. RFC 3095 has some unclear words about this only in the R-mode section, but this is a general thing. Mode transition can never be initiated before the decompressor has received and correctly decompressed at least one packet. This should be obvious if one consider that modes is a per-profile thing, and so are the feedback packet bits that are used to signal mode transition. First when a packet has been correctly decompressed and the context has been established, the decompressor knows which profile it is operating according to, and thus which modes are available. Lars-Erik further raised a question about a statement in the draft concerning the use of Extension-3 with UO-1* packets. The statement says that "it might not make sense to use these packets", and the point was that such statements should not be made if we do not have specific reasons to do so. Mark agreed that the implementers guide should not make moral judgements, and it was decided to keep the clarification, but not say whether use of UO-1* with Extension-3 is a good or bad idea. Draft: draft-ietf-rohc-rtp-impl-guide-00.txt The next RFC 3095 interoperability test will take place in Lulea Sweden, April 17-23, hosted by Ericsson. Lars-Erik pointed out that newcomers are more than welcome, since it would be useful to get some fresh code and new problems to play with. - MIB, news & open issues (Quittek) Juergen reported on the MIB progress, which unfortunately has been less than we expected in December. One difficult thing is that the architecture of ROHC is not on solid ground, and this complicates the MIB development. Changes from the first version is mainly a new chapter stating architectural assumptions, a merge of the interface and header groups, and some new basic properties, such as version and manufacturer. The statistics group must be considered further to find out what things are useful there. Carsten pointed out that header types might not be a very good measure, since with TCP we might have hundreds of header types, and even with RTP the same header could be used with various options. It was suggested to have this as an action point for the next ROHC interop. Implementers should report what counters and information they collect in their implementations. There was a question about the grouping of the statistic counters. Juergen answered that this is due to restrictions from the MIB structure, one cannot put everything in the same table. Some statistics are outside of the statistics group, which only holds sophisticated counters. Regarding the architectural assumptions, Lars-Erik pointed out that a minimal instance is a compressor or a decompressor, which is not obvious from the current MIB. Juergen answered that an instance could be either a compressor, a decompressor, or both, and this will be made clearer in the next version. Lars-Erik is planning to write an architectural document for ROHC, and that might simplify these discussions. The next question was whether we plan to have MIBs for TCP or other compression protocols as well. The answer is yes, but we have to start with RTP. However, it would probably be a good time to start discussing a possible MIB structure and prepare for integration of other protocols as well. Carsten noted that understanding of the ROHC standard increases when doing the MIB, and the understanding will also increase when RFC 3095 is divided. Finally, Juergen asked if anyone is planning to implement the MIB, but there were no answers from the room. Carsten pointed out that someone will have to implement this, and encouraged people to go home and see who needs a MIB. Network builders will most likely need the MIB. Draft: draft-ietf-rohc-mib-rtp-01.txt - LLA, implementation examples (Pelletier) During the LLA development, a draft was written to illustrate how the LLA profile could be implemented in a typical environment, such as CDMA2000. It was then agreed to produce an Informational RFC based on this material, enhanced with more examples. Currently, the original draft has expired and we still have no WG draft for this, basically because the LLA incorporation in CDMA2000 has not yet been finalized. However, that work is now almost completed and we should soon expect to get a first version of this draft as a WG document. - UDP-Lite profiles, initial discussions (Pelletier) Ghyslain Pelletier held an initial discussion about profiles for UDP-Lite, based on his new draft. The current draft does not provide a complete solution, but is more about motivating and suggesting a direction for the work. There are no profile details, such as packet structures, included yet. The difference between UDP and UDP-Lite is that the length field of UDP has been replaced with a checksum coverage field, indicating how much of the payload has been covered by the checksum. It thus affects both the length/coverage field and the checksum field. For header compression, this means we get a new field that can not be inferred (length could be inferred from link layer, coverage could probably not). UDP-Lite has been defined to provide more flexibility to choose the level of protection provided by the transport layer, which is often desirable for applications such as conversational audio/video. In IPv4, the UDP checksum can be disabled, but that is not the case for IPv6. The reason for that is to guarantee protection for the headers, and therefore UDP Lite require, as a minimum, the header part of the packet to always be covered by the checksum. Depending on how the coverage field is set, one can identify typical scenarios for UDP-Lite usage, and the basic idea is to provide different compression approaches for different usage scenarios, making it possible to optimize compression for certain cases. A discussion followed about the possible common coverage for codec payloads such as AMR and EVRC, whether the payload header will be covered, and maybe even parts of the payload itself. Another question was whether this can change on a per-packet basis, and in such case how frequently? There was no real conclusion, more than that the coverage might vary on a short term basis, and that it is reasonable to believe one wants to protect at least the payload header. This should be subject for further investigation. The UDP-Lite profile will of course have to handle all possible UDP-Lite usage scenarios, but the proposal is to optimize for some cases that can be optimized for. The suggestion is to allow removal of the UDP-lite checksum at the compressor, with recalculation at the decompressor, for these specific cases. The use of this optimization would be limited to e.g. when only the packet headers were covered by the checksum, but could give a substantial performance gain. This would allow us to potentially compress as efficient in IPv6 as in IPv4 (where the checksum might be disabled). A discussion followed about the end-to-end consequences of this approach, how useful this would be since normally also the payload will be covered, etc. Stephen Casner argued that this breaks the end-2-end meaning of the UDP checksum, while Ghyslain answered that this is not completely true and the draft motivates why. There were no real conclusions, but more discussions and explanations were requested. Carsten Bormann said he wanted to explain why he allowed this to be brought up at all. UDP-Lite is not UDP, but was created with the purpose of playing with checksums. UDP-lite is necessary, because of the defect of IPv6 not allowing the UDP checksum to be disabled, and UDP-lite exists to fix this. Therefore it is good to look at options in the compression of UDP-lite. There was a question on what the minimal compressed header size would be, which Ghyslain answered would depend on the size of the CRC used, and so on. Another question asked about the relationship to 0-byte compression, which we already have. Why do we need this? Ghyslain answered that LLA doesn't work with v6, and this is targeting a different particular need - dealing with UDP-lite. Lars-Erik suggested there should be comparisons to the IPv4 case, where the header checksum is taken away in ROHC. The IPv6 header has no checksum, instead the UDP checksum is mandated. What would be the difference between these cases? This is an interesting analogy, and Carsten suggested it should be taken up in the draft. Lars-Erik pointed out that independent of which approach we finally go for, with or without certain optimizations, we are chartered to do profiles for UDP-Lite. This is therefore a good starting point for discussions. Finally, Stephen Casner suggested to investigate whether the coverage field could potentially be inferred from the link layer. To make a difference with UDP-Lite, link layers would also have to provide for partial protection, and that should then be utilized. Draft: draft-pelletier-rohc-rtp-udp-lite-00.txt -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Fri Apr 12 18:50:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06132 for ; Fri, 12 Apr 2002 18:50:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19013; Fri, 12 Apr 2002 18:48:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18979 for ; Fri, 12 Apr 2002 18:48:47 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06067 for ; Fri, 12 Apr 2002 18:48:44 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3CMmjs7007903 for ; Sat, 13 Apr 2002 00:48:45 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Apr 13 00:48:45 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 13 Apr 2002 00:38:21 +0200 Message-ID: From: "Lars-Erik Jonsson (EPL)" To: "Hans Hannu (EPL)" , "'rohc@ietf.org'" Subject: RE: [rohc] sigcomp issue list Date: Sat, 13 Apr 2002 00:48:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org Hans, Could you please update the list and clarify what actions have been taken. Under "action", you now mostly list "responses", while I would also like to see what has been changed in the drafts, if anything has been changed. E.g. for the first issue, has this text been corrected??? Others, please look at this list and let us together agree to close the issues that have been resolved. BR /Lars-Erik > -----Original Message----- > From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se] > Sent: den 10 april 2002 09:11 > To: 'rohc@ietf.org' > Subject: RE: [rohc] sigcomp issue list > > > Hi, > > The current sigcomp issue list can be found at: > http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm > > This is a cut and paste summary of the work that the authors > have done when trying to close the issues. > Take a look and see what you think so that we can close the > issues and submit the updated SigComp and SigComp-extended drafts. > > BR > /Hans H > > > -----Original Message----- > > From: Dr. Carsten Bormann [mailto:cabo@tzi.org] > > Sent: den 18 mars 2002 20:30 > > To: Dr. Carsten Bormann; rohc@ietf.org > > Subject: RE: [rohc] sigcomp issue list > > > > > > Sigcompers, > > > > I have compile some information from the various issues > > posting that have > > been on the mailing list. > > I hope this is a useful recap for people preparing for > > tomorrow's meeting. > > I'm not claiming any of this is authoritative. > > If you reply (please do), please change the subject to > "sigcomp issue > > xxx-nn", where xxx-nn is the issue number. > > > > 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 rohc-admin@ietf.org Sat Apr 13 04:30:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22591 for ; Sat, 13 Apr 2002 04:30:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20310; Sat, 13 Apr 2002 04:27:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20279 for ; Sat, 13 Apr 2002 04:27:42 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22577 for ; Sat, 13 Apr 2002 04:27:39 -0400 (EDT) Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3D8RIf21238; Sat, 13 Apr 2002 10:27:27 +0200 (MEST) X-Mailer: emacs 21.2.1 (via feedmail 8 I) To: "Lars-Erik Jonsson (EPL)" Cc: "Hans Hannu (EPL)" , "'rohc@ietf.org'" Subject: Re: [rohc] sigcomp issue list References: From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann) Date: 13 Apr 2002 10:27:26 +0200 In-Reply-To: Message-ID: Lines: 132 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org I would propose a slightly more elaborate format for the issues list, as exemplified by the following three examples. In particular, I'd like to see a relatively small number of "states" an issue can be in, which need to mesh with a RFC2026/2418 view of the standards process. Gruesse, Carsten PS.: Oh, and please demicrosoftize (as exemplified, too). ________________________________________________________________________ lejo-1 : Resolution proposed in current editors' working document _________________________________ Issue: In section 3.1 (page 9), it is written that SigComp usage is indicated by using different port numbers. Did we not agree that this is one option, but not necessary the way it is done. SigComp essages are now self-identifiable. _________________________________ Discussion: Carsten: I believe the consensus is that Sigcomp should be open to a number of ways to do the multiplexing; sigcomp itself contributes identifiable messages, but using port numbers or some other scheme definitely remains possible. SigComp-05a messages are self-identifiable I have one small question on this issue. SigComp messages are recognizable from UTF-8 encoded text because of the following: "Now, since RFC2044 (October 1996), Unicode has been decided to stop at 0010 FFFF" However I can't find a mention of this in the latest RFC on the subject [RFC-2279]. Did I miss it in the RFC, or is there a separate document on the subject that we could reference in SigComp? Carsten: This was not done in IETF space, but in the Unicode/JTC1-SC2 environment. See http://std.dkuug.dk/JTC1/SC2/WG2/docs/n2175.htm By the way, a good intro into Unicode is at http://oss.software.ibm.com/icu/userguide/unicodeBasics.html _________________________________ Action: Text in 3.1 now says: All SigComp messages contain a prefix that does not occur in UTF-8 encoded text messages [RFC-2279], so for applications which use this encoding it is possible to multiplex uncompressed application messages and SigComp messages on the same port. Applications can still reserve a new port specifically for SigComp however (e.g. as part of the discovery mechanism). ________________________________________________________________________ lejo-2 : Proposed: No action needed _________________________________ Issue: Use of static dictionaries, how is that envisioned? First of all, I assume it should be mentioned and explained, e.g. when per-message compression is defined. Further, 6.3.3 may be interpreted as if static dictionary usage is about announcing certain pre-defined states. Is that a good approach? Should one not define a static dictionary for each SigComp application, e.g. SIP, that must be used as a minimum? _________________________________ Discussion: Carsten: The sense of the IETF-3GPP ad-hoc on this was, yes, we should define one such static dictionary for SIP. It is static in that it really does not change, even if further extensions get added to SIP. A design team comprising Carsten, Richard and some SIP/SDP/SIPPING people will construct a static dictionary for use with SIP/SDP. This is not part of SigComp. I used the example of the SIP static dictionary in Section 3.3.3 when explaining about locally available state. It would be useful to add a specific reference to the dictionary (assuming we decide to publish as a separate document). _________________________________ Action: No action needed in sigcomp itself. ________________________________________________________________________ lejo-3 : Resolution proposed in current editors' working document _________________________________ Issue: We must standardize how SigComp is used for e.g. SIP (at least). This includes default values for all application parameters, the mechanism used to separate SigComp/SIP from normal SIP messages, and maybe a mandatory static dictionary. _________________________________ Discussion: Carsten: See lejo-2 above. For the parameters, let's see how they distill (cabo-15); once this is done, it may be almost obvious what to use for SIP. The whole thing should be specified in an annex to sigcomp, to clearly identify it as something that is separate from sigcomp itself, or, alternatively, as a separate draft. Default parameter values are defined in SigComp-05a. See also lejo-2 We managed to dispose of every parameter apart from the ones that can be announced using the SigComp feedback mechanism. Therefore, we normally take the default value for each parameter to be the minimum possible (after all, we can always announce higher values if they are available). The only exception to the above is if we feel that for a particular application, it would be useful to offer additional resources as mandatory. For example we believe that a mandatory static dictionary is useful in SIP/SDP. We'll have to standardize these additional resources on a case-by-case basis as we are doing for SIP/SDP. _________________________________ Action: Text in 3.3 now specifies the default values for parameters; these should be useful for SIP/SDP compression as they are. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Mon Apr 15 02:51:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08343 for ; Mon, 15 Apr 2002 02:51:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17552; Mon, 15 Apr 2002 02:41:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09105 for ; Sat, 13 Apr 2002 12:38:34 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27095 for ; Sat, 13 Apr 2002 12:38:26 -0400 (EDT) Received: from m2vwall2.wipro.com ([164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g3DGbtv06858 for ; Sat, 13 Apr 2002 22:07:55 +0530 (IST) Received: from m2vwall3.wipro.com ([164.164.29.237]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUIM5O00.IC2 for ; Sat, 13 Apr 2002 22:07:00 +0530 Received: from 164.164.23.9 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Sat, 13 Apr 2002 22:04:01 +0530 Received: from ecvwall1.wipro.com ([164.164.23.6]) by mailstore.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUFXJT00.J2U for ; Fri, 12 Apr 2002 11:20:17 +0530 Received: from wipro.com ([10.113.1.100]) by ggnmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GUFXJP00.I1Y; Fri, 12 Apr 2002 11:20:13 +0530 Message-ID: <3CB67550.58237FF1@wipro.com> Date: Fri, 12 Apr 2002 11:19:04 +0530 From: Lalit Bhasin Organization: WIPRO TECHNOLOGY X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lee lik sun CC: rohc@ietf.org Subject: Re: [rohc] rohc query References: <3CB5549A.DB0DC67D@wipro.com> <001e01c1e1c0$39a88380$0b1510ac@psl.com.sg> Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d30ddd55-4dd2-11d6-a942-00b0d0d06be8" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org ------=_NextPartTM-000-d30ddd55-4dd2-11d6-a942-00b0d0d06be8 Content-Type: multipart/alternative; boundary="------------662DED2FEDD95CDA3366EF9D" --------------662DED2FEDD95CDA3366EF9D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lee, Does that means that the outer IP-ID would be sent in uncompressed form even if the IP-ID is showing the sequential behaviour. If this is the case, can't we assume that the outer IP-ID is behaving as random (ie assume that RND2 flag is set) and send it in the ROHC packet after the extension. Thus the extension 3 would not be used everytime in IPv4-Ipv4 tuneeling. Regds, Lalit Bhasin Lee lik sun wrote: > Hi Lalit & all, > > Please correct my understanding if i am wrong. > > IF both RND & RND2 flags are 0. > > encoded IP-ID bits of the inner IPv4 header can sent in the type 0,1 & 2. > But the IP-ID of the outer IPV4 header will have to be sent with an > extension 3 > with the Outer IP header flag (ip2) set and the IP-ID is sent uncompressed > with I2 > of the Outer IP header flag set. > > thanks & regards > LEE lik sun > > ----- Original Message ----- > From: Lalit Bhasin > To: > Sent: Thursday, April 11, 2002 5:17 PM > Subject: [rohc] rohc query > > > hi all, > > In case of IPv4-IPv4 tunneling, if the RND and RND2 flags are 0, > > how is the encoded IP-ID bits of the outer IPv4 header > > sent in the type 0,1 and 2 packets. The base header of these packets > > only carry the encoded IP-ID bits of inner IPv4 header. > > thanks in advance.. > > Lalit > > > > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc -- ******************************* LALIT KUMAR BHASIN WIPRO TECHNOLOGIES GURGAON. Ph. 0124-6398465-69 Ext 2019 9810419594 ******************************** --------------662DED2FEDD95CDA3366EF9D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Lee,
  Does that means that the outer IP-ID would be sent in uncompressed form even if the
IP-ID is showing the sequential behaviour.
If this is the case, can't we assume that the outer IP-ID is behaving as random
(ie assume that RND2 flag is set) and send it in the ROHC packet after the extension. Thus the
extension 3 would not be used everytime in IPv4-Ipv4 tuneeling.
Regds,
Lalit Bhasin
 
 

Lee lik sun wrote:

Hi Lalit & all,

Please correct my understanding if i am wrong.

IF both RND & RND2 flags are 0.

encoded IP-ID bits of the inner IPv4 header can sent in the type 0,1 & 2.
But the IP-ID of the outer IPV4 header will have to be sent with an
extension 3
with the Outer IP header flag (ip2) set and the IP-ID is sent uncompressed
with I2
of the Outer IP header flag set.

thanks & regards
LEE lik sun

----- Original Message -----
From: Lalit Bhasin <lalit.bhasin@wipro.com>
To: <rohc@ietf.org>
Sent: Thursday, April 11, 2002 5:17 PM
Subject: [rohc] rohc query

> hi all,
>       In case of  IPv4-IPv4 tunneling, if the RND and RND2 flags are 0,
> how is the encoded IP-ID bits of the outer IPv4 header
> sent in the type 0,1 and 2 packets. The base header of these packets
> only carry the encoded IP-ID bits of inner IPv4 header.
> thanks in advance..
> Lalit
>
>
>

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc

-- 

*******************************
LALIT KUMAR BHASIN
WIPRO TECHNOLOGIES
GURGAON.
Ph. 0124-6398465-69 Ext 2019
    9810419594
********************************
  --------------662DED2FEDD95CDA3366EF9D-- ------=_NextPartTM-000-d30ddd55-4dd2-11d6-a942-00b0d0d06be8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-d30ddd55-4dd2-11d6-a942-00b0d0d06be8-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-admin@ietf.org Mon Apr 15 03:58:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09138 for ; Mon, 15 Apr 2002 03:58:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23561; Mon, 15 Apr 2002 03:50:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23532 for ; Mon, 15 Apr 2002 03:50:50 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09032 for ; Mon, 15 Apr 2002 03:50:45 -0400 (EDT) Received: from m2vwall2.wipro.com ([164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g3F7oGv01800 for ; Mon, 15 Apr 2002 13:20:16 +0530 (IST) Received: from m2vwall3.wipro.com ([164.164.29.237]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GULMZ200.9XG for ; Mon, 15 Apr 2002 13:17:26 +0530 Received: from 164.164.23.9 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 13:00:44 +0530 Received: from ecvwall1.wipro.com ([164.164.23.6]) by mailstore.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GULM6E00.P5M for ; Mon, 15 Apr 2002 13:00:14 +0530 Received: from wipro.com ([10.113.1.100]) by ggnmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GULM6B00.U36; Mon, 15 Apr 2002 13:00:11 +0530 Message-ID: <3CBA813E.90A3549A@wipro.com> Date: Mon, 15 Apr 2002 12:59:02 +0530 From: Lalit Bhasin Organization: WIPRO TECHNOLOGY X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Carsten Bormann CC: rohc@ietf.org Subject: Re: [rohc] segmentation issue.... References: <3CB68607.84F187D4@wipro.com> <3CB72C39.506@tzi.org> Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-c93aabd9-5035-11d6-a942-00b0d0d06be8" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Robust Header Compression X-BeenThere: rohc@ietf.org ------=_NextPartTM-000-c93aabd9-5035-11d6-a942-00b0d0d06be8 Content-Type: multipart/alternative; boundary="------------25BEC2F4247407704B4AD061" --------------25BEC2F4247407704B4AD061 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Agreed, that means the segmentation header is never preceeded by Add-CID. If that is the case, the section 5.2.6 ( ROHC initial decompressor processing) point 5 states that : If the first remaining octet starts with 1111111, this is a segment. Shouldn't it be like this : If the first remaining octet starts with 1111111 and an Add-CID octet was not found in step 2), this is a segment. Lalit Bhasin Carsten Bormann wrote: > Lalit Bhasin wrote: > > hi all, > > As per RFC 3095 Section 5.2.5.2 SEGMENTATION PROTOCOL, the Segment > > header doesn't carry a CID. > > In the same section, later it is written that the CID is derived from > > the initial octets of the reconstructed unit. These two > > statements are contradicting each other. It is not clear that why the > > CID should not be a part of the Segment header. > > Hi Lalit, > > the idea is that the segmentation header itself does not have a CID. > So all the tiny segments being put together to one reconstructed unit do > not carry a CID. Then, the reconstructed unit is treated like a ROHC > packet, and can carry a CID. No contradiction. (If you look at the > bits on the wire, most likely the CID will be in the *segment* of the > first packet -- not in the segmentation header, and not in any other > packets contributing to the reconstructed unit.) > > > Information contained in this E-MAIL being proprietary to Wipro Limited > > is 'privileged' and 'confidential' > > No. This is a submission to an IETF mailing list, so you submit to the > IETF rules. (I know I'm picky today, but this has to be stressed > occasionally.) > > Gruesse, Carsten --------------25BEC2F4247407704B4AD061 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Agreed, that means the segmentation header is never preceeded by Add-CID.
If that is the case, the section 5.2.6 ( ROHC initial decompressor processing) point 5 states that :
 
  If the first remaining  octet starts with 1111111, this is a segment.

Shouldn't it be like this :

 If the first remaining octet starts with 1111111 and an Add-CID octet was not found
in step 2), this is a segment.
 
Lalit Bhasin
 
 

Carsten Bormann wrote:

Lalit Bhasin wrote:
> hi all,
>    As per RFC 3095 Section 5.2.5.2 SEGMENTATION PROTOCOL, the Segment
> header doesn't carry a CID.
> In the same section, later it is written that the CID is derived from
> the initial octets of the reconstructed unit. These two
> statements are contradicting each other. It is not clear that why the
> CID should not be a part of the Segment header.

Hi Lalit,

the idea is that the segmentation header itself does not have a CID.
So all the tiny segments being put together to one reconstructed unit do
not carry a CID.  Then, the reconstructed unit is treated like a ROHC
packet, and can carry a CID.  No contradiction.  (If you look at the
bits on the wire, most likely the CID will be in the *segment* of the
first packet -- not in the segmentation header, and not in any other
packets contributing to the reconstructed unit.)

> Information contained in this E-MAIL being proprietary to Wipro Limited
> is 'privileged' and 'confidential'

No.  This is a submission to an IETF mailing list, so you submit to the
IETF rules.  (I know I'm picky today, but this has to be stressed
occasionally.)

Gruesse, Carsten


 

--------------25BEC2F4247407704B4AD061--



------=_NextPartTM-000-c93aabd9-5035-11d6-a942-00b0d0d06be8
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.
********************************************************************

------=_NextPartTM-000-c93aabd9-5035-11d6-a942-00b0d0d06be8--


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 04:31:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10040
	for ; Mon, 15 Apr 2002 04:31:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27050;
	Mon, 15 Apr 2002 04:19:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27000
	for ; Mon, 15 Apr 2002 04:19:42 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09842
	for ; Mon, 15 Apr 2002 04:19:34 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3F8JV3G000289
	for ; Mon, 15 Apr 2002 10:19:32 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 15 10:17:30 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 15 Apr 2002 10:07:03 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'Lalit Bhasin'" ,
        Carsten Bormann
	 
Cc: rohc@ietf.org
Subject: RE: [rohc] segmentation issue....
Date: Mon, 15 Apr 2002 10:17:04 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E455.ED6ECFE0"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1E455.ED6ECFE0
Content-Type: text/plain;
	charset="iso-8859-1"

This is captured by 5), which states that reconstructed packets can not include segments, padding or feedback.
 
/L-E
 

-----Original Message-----
From: Lalit Bhasin [mailto:lalit.bhasin@wipro.com]
Sent: den 15 april 2002 09:29
To: Carsten Bormann
Cc: rohc@ietf.org
Subject: Re: [rohc] segmentation issue....


Agreed, that means the segmentation header is never preceeded by Add-CID. 
If that is the case, the section 5.2.6 ( ROHC initial decompressor processing) point 5 states that : 
  
  If the first remaining  octet starts with 1111111, this is a segment. 

Shouldn't it be like this : 


 If the first remaining octet starts with 1111111 and an Add-CID octet was not found 
in step 2), this is a segment. 
  
Lalit Bhasin 
  
  


Carsten Bormann wrote: 


Lalit Bhasin wrote: 
> hi all, 
>    As per RFC 3095 Section 5.2.5.2 SEGMENTATION PROTOCOL, the Segment 
> header doesn't carry a CID. 
> In the same section, later it is written that the CID is derived from 
> the initial octets of the reconstructed unit. These two 
> statements are contradicting each other. It is not clear that why the 
> CID should not be a part of the Segment header. 

Hi Lalit, 


the idea is that the segmentation header itself does not have a CID. 
So all the tiny segments being put together to one reconstructed unit do 
not carry a CID.  Then, the reconstructed unit is treated like a ROHC 
packet, and can carry a CID.  No contradiction.  (If you look at the 
bits on the wire, most likely the CID will be in the *segment* of the 
first packet -- not in the segmentation header, and not in any other 
packets contributing to the reconstructed unit.) 


> Information contained in this E-MAIL being proprietary to Wipro Limited 
> is 'privileged' and 'confidential' 


No.  This is a submission to an IETF mailing list, so you submit to the 
IETF rules.  (I know I'm picky today, but this has to be stressed 
occasionally.) 


Gruesse, Carsten


  


------_=_NextPart_001_01C1E455.ED6ECFE0
Content-Type: text/html;
	charset="iso-8859-1"









This 
is captured by 5), which states that reconstructed packets can not include 
segments, padding or feedback.


 


/L-E


 



  
-----Original Message-----
From: Lalit Bhasin 
  [mailto:lalit.bhasin@wipro.com]
Sent: den 15 april 2002 
  09:29
To: Carsten Bormann
Cc: 
  rohc@ietf.org
Subject: Re: [rohc] segmentation 
  issue....

Agreed, that means the segmentation header is 
  never preceeded by Add-CID. 
If that is the case, the section 5.2.6 ( ROHC 
  initial decompressor processing) point 5 states that : 
  
  
  If the first remaining  octet starts with 1111111, this is a segment. 
  
Shouldn't it be like this : 
  
 If the first remaining octet starts with 1111111 and an Add-CID octet 
  was not found 
in step 2), this is a segment. 
  
Lalit Bhasin 
  
  
  
  
Carsten Bormann wrote: 
  
Lalit Bhasin wrote: 
> hi all, 
    
>    As per RFC 3095 Section 5.2.5.2 SEGMENTATION 
    PROTOCOL, the Segment 
> header doesn't carry a CID. 
> In the 
    same section, later it is written that the CID is derived from 
> the 
    initial octets of the reconstructed unit. These two 
> statements are 
    contradicting each other. It is not clear that why the 
> CID should 
    not be a part of the Segment header. 
    
Hi Lalit, 
    
the idea is that the segmentation header itself does not have a CID. 
    
So all the tiny segments being put together to one reconstructed unit do 
    
not carry a CID.  Then, the reconstructed unit is treated like a 
    ROHC 
packet, and can carry a CID.  No contradiction.  (If you 
    look at the 
bits on the wire, most likely the CID will be in the 
    *segment* of the 
first packet -- not in the segmentation header, and not 
    in any other 
packets contributing to the reconstructed unit.) 
    
> Information contained in this E-MAIL being proprietary to Wipro 
    Limited 
> is 'privileged' and 'confidential' 
    
No.  This is a submission to an IETF mailing list, so you submit to 
    the 
IETF rules.  (I know I'm picky today, but this has to be 
    stressed 
occasionally.) 
    
Gruesse, Carsten
  


------_=_NextPart_001_01C1E455.ED6ECFE0--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 04:37:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10112
	for ; Mon, 15 Apr 2002 04:37:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27848;
	Mon, 15 Apr 2002 04:31:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27813
	for ; Mon, 15 Apr 2002 04:31:53 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10056
	for ; Mon, 15 Apr 2002 04:31:49 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3F8Vo3G010801
	for ; Mon, 15 Apr 2002 10:31:50 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 15 10:31:37 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 15 Apr 2002 10:21:10 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "Lars-Erik Jonsson (EPL)" ,
        "'Lalit Bhasin'" ,
        Carsten Bormann 
Cc: rohc@ietf.org
Subject: RE: [rohc] segmentation issue....
Date: Mon, 15 Apr 2002 10:31:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E457.E85C5F20"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1E457.E85C5F20
Content-Type: text/plain;
	charset="iso-8859-1"

Hi again,
 
Ignore my previous answer. You are right that this is not completely clear. Section 5.2.5.2 says that a
segment may be preceded by padding octets and/or feedback. However, it is not clear from 5.2.6 that
Add-CID is not allowed in front of a segment. Your comment below is thus correct, that is how one
should interpret the spec.
 
BR
/L-E


-----Original Message-----
From: Lars-Erik Jonsson (EPL) [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
Sent: den 15 april 2002 10:17
To: 'Lalit Bhasin'; Carsten Bormann
Cc: rohc@ietf.org
Subject: RE: [rohc] segmentation issue....


This is captured by 5), which states that reconstructed packets can not include segments, padding or feedback.
 
/L-E
 

-----Original Message-----
From: Lalit Bhasin [mailto:lalit.bhasin@wipro.com]
Sent: den 15 april 2002 09:29
To: Carsten Bormann
Cc: rohc@ietf.org
Subject: Re: [rohc] segmentation issue....


Agreed, that means the segmentation header is never preceeded by Add-CID. 
If that is the case, the section 5.2.6 ( ROHC initial decompressor processing) point 5 states that : 
  
  If the first remaining  octet starts with 1111111, this is a segment. 

Shouldn't it be like this : 


 If the first remaining octet starts with 1111111 and an Add-CID octet was not found 
in step 2), this is a segment. 
  
Lalit Bhasin 
  
  


Carsten Bormann wrote: 


Lalit Bhasin wrote: 
> hi all, 
>    As per RFC 3095 Section 5.2.5.2 SEGMENTATION PROTOCOL, the Segment 
> header doesn't carry a CID. 
> In the same section, later it is written that the CID is derived from 
> the initial octets of the reconstructed unit. These two 
> statements are contradicting each other. It is not clear that why the 
> CID should not be a part of the Segment header. 

Hi Lalit, 


the idea is that the segmentation header itself does not have a CID. 
So all the tiny segments being put together to one reconstructed unit do 
not carry a CID.  Then, the reconstructed unit is treated like a ROHC 
packet, and can carry a CID.  No contradiction.  (If you look at the 
bits on the wire, most likely the CID will be in the *segment* of the 
first packet -- not in the segmentation header, and not in any other 
packets contributing to the reconstructed unit.) 


> Information contained in this E-MAIL being proprietary to Wipro Limited 
> is 'privileged' and 'confidential' 


No.  This is a submission to an IETF mailing list, so you submit to the 
IETF rules.  (I know I'm picky today, but this has to be stressed 
occasionally.) 


Gruesse, Carsten


  


------_=_NextPart_001_01C1E457.E85C5F20
Content-Type: text/html;
	charset="iso-8859-1"









Hi 
again,


 


Ignore 
my previous answer. You are right that this is not completely clear. Section 
5.2.5.2 says that a


segment may be preceded by padding octets and/or 
feedback. However, it is not clear from 5.2.6 that


Add-CID is not allowed in front of a segment. Your 
comment below is thus correct, that is how one


should 
interpret the spec.


 


BR


/L-E



  
-----Original Message-----
From: Lars-Erik Jonsson (EPL) 
  [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
Sent: den 15 april 2002 
  10:17
To: 'Lalit Bhasin'; Carsten Bormann
Cc: 
  rohc@ietf.org
Subject: RE: [rohc] segmentation 
  issue....


  
This 
  is captured by 5), which states that reconstructed packets can not include 
  segments, padding or feedback.

  
 

  
/L-E

  
 

  

    
-----Original Message-----
From: Lalit Bhasin 
    [mailto:lalit.bhasin@wipro.com]
Sent: den 15 april 2002 
    09:29
To: Carsten Bormann
Cc: 
    rohc@ietf.org
Subject: Re: [rohc] segmentation 
    issue....

Agreed, that means the segmentation header is 
    never preceeded by Add-CID. 
If that is the case, the section 5.2.6 ( 
    ROHC initial decompressor processing) point 5 states that : 
  
    
  If the first remaining  octet starts with 1111111, this is a 
    segment. 
    
Shouldn't it be like this : 
    
 If the first remaining octet starts with 1111111 and an Add-CID 
    octet was not found 
in step 2), this is a segment. 
  
Lalit 
    Bhasin 
  
  
    
Carsten Bormann wrote: 
    
Lalit Bhasin wrote: 
> hi all, 
      
>    As per RFC 3095 Section 5.2.5.2 SEGMENTATION 
      PROTOCOL, the Segment 
> header doesn't carry a CID. 
> In the 
      same section, later it is written that the CID is derived from 
> 
      the initial octets of the reconstructed unit. These two 
> 
      statements are contradicting each other. It is not clear that why the 
      
> CID should not be a part of the Segment header. 
      
Hi Lalit, 
      
the idea is that the segmentation header itself does not have a CID. 
      
So all the tiny segments being put together to one reconstructed unit 
      do 
not carry a CID.  Then, the reconstructed unit is treated like 
      a ROHC 
packet, and can carry a CID.  No contradiction.  (If 
      you look at the 
bits on the wire, most likely the CID will be in the 
      *segment* of the 
first packet -- not in the segmentation header, and 
      not in any other 
packets contributing to the reconstructed unit.) 
      
> Information contained in this E-MAIL being proprietary to Wipro 
      Limited 
> is 'privileged' and 'confidential' 
      
No.  This is a submission to an IETF mailing list, so you submit 
      to the 
IETF rules.  (I know I'm picky today, but this has to be 
      stressed 
occasionally.) 
      
Gruesse, Carsten
  


------_=_NextPart_001_01C1E457.E85C5F20--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 06:26:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12221
	for ; Mon, 15 Apr 2002 06:26:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02769;
	Mon, 15 Apr 2002 06:15:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02732
	for ; Mon, 15 Apr 2002 06:15:12 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11674
	for ; Mon, 15 Apr 2002 06:15:09 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3FAFA3G029523
	for ; Mon, 15 Apr 2002 12:15:10 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 15 12:14:36 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 15 Apr 2002 12:04:09 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'Robert.Sugar@nokia.com'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
Date: Mon, 15 Apr 2002 12:14:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> 
>  The effort to be change the draft: New instruction 
> STATE_FREE, possibly removing the automatic state deletion, 
> describing all this.

As a last resort in case of message loss/misordering SigComp should have the automatic state deletion.

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 06:30:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12277
	for ; Mon, 15 Apr 2002 06:30:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02891;
	Mon, 15 Apr 2002 06:19:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02862
	for ; Mon, 15 Apr 2002 06:19:17 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12141
	for ; Mon, 15 Apr 2002 06:19:14 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3FAJEs7013209
	for ; Mon, 15 Apr 2002 12:19:14 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 15 12:17:09 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTKQL2>; Mon, 15 Apr 2002 12:14:35 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'zhigang.c.liu@nokia.com'" ,
        Robert.Sugar@nokia.com, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
Date: Mon, 15 Apr 2002 12:16:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

Just to see whether I've understood:

The functionality of the STATE-FREE is: "The compressor using the STATE-FREE instruction tells its remote decomressor that this state will not be used anymore."

What does the decompressor do when it encounters the STATE-FREE instruction?
a) It MUST delete the indicated state?
b) It MAY delete the indicated state?

One more thing.
Should the STATE-FREE instruction also be taken to mean that: "After deletion of the indicate state the decompressor's allocated state_memory for the compressor is reduced with the size of the deleted state" ?

BR
/Hans H


 

 	

> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: den 12 april 2002 23:09
> To: Hans.Hannu@epl.ericsson.se; Robert.Sugar@nokia.com; rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
> 
> 
> > Hmm, so what you're after is a way to change the 
> > state_retention_priority and not explicitly tell the 
> > decompressor that "I'll not use this state anymore" but 
> > rather change the priority and let the deletion rule still be 
> > as it is. 
> 
> Hans,
> 
> Sorry, I wasn't clear. What I described is one example to use
> STATE_FREE instruction. STATE_FREE does mean that "I'll not
> use this state anymore". This is independent of state priority.
> 
> Robert already explained it pretty well: "This way the memory 
> does not have to fill up before removing any states". The point
> is that there is something a compressor can do with STATE_FREE,
> but not with priority. Of course, a compressor can feel free
> to consume all the memory allocated to it. But on the other
> hand, we should give it a chance to be nicer (to the receiving
> sigcomp) if it wants to. 
> 
> One additional point: I don't think priority approach and 
> STATE_FREE is mutual exclusive. And I don't think they have
> to be bundled together. Both have their own merit and we
> should give implementer the freedom. Having said good words 
> on STATE_FREE, the priority approach may be more efficient 
> since you can use small amount of bits (for priority) 
> per message to control the deletion. That can also be done
> via STATE_FREE, but in a trickier way. E.g. you refer to one
> state (cost you >= 6 bytes) that contains hash values
> of other states; then in the sigcomp message, you only need 
> to send a few bits to tell which one of the states you
> want to apply STATE_FREE. This avoids sending additional
> state_ID in the message, but needs a bit more complicated UDVM
> code.
> 
> Zhigang
> 
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 06:30:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12289
	for ; Mon, 15 Apr 2002 06:30:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02485;
	Mon, 15 Apr 2002 06:10:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02442
	for ; Mon, 15 Apr 2002 06:09:56 -0400 (EDT)
Received: from mail-jpn.microsoft.com (mail-jpn.microsoft.com [207.46.71.29])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11235
	for ; Mon, 15 Apr 2002 06:09:51 -0400 (EDT)
Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 19:09:23 +0900
Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 19:09:23 +0900
Received: from bjs-msg-01.fareast.corp.microsoft.com ([157.60.72.120]) by jpn-imc-01.fareast.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 19:09:23 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
Subject: RE: [rohc] proposals for generic notation of compressed header
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Mon, 15 Apr 2002 18:09:22 +0800
Message-ID: 
Thread-Topic: [rohc] proposals for generic notation of compressed header
Thread-Index: AcHg5oyTzcB5URRwQZKz12n+siTULwDfumVw
From: "Qian Zhang" 
To: "West, Mark (ITN)" 
Cc: 
X-OriginalArrivalTime: 15 Apr 2002 10:09:23.0076 (UTC) FILETIME=[9DA52440:01C1E465]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA02444
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Hi, Mark

Comments inline again..., :)

Cheers,

Qian & Hongbin


> 
> Qian Zhang wrote:
> 
> > [removed to save space, however, need we save the earth first? just
> > a joke.]
> 
> I don't think that it's *quite* that simple!  The notation is 
> capturing two things: the structure of the header and how to encode 
> it.  So, there has to be some way of identifying the IP reserved flags

> and the TCP reserved flags as well.
> 
> The important point about removing the stack manipulation encodings is
> that they impose a particular solution (and one that's quite messy to 
> use!)
> 

Yeah, agree. We really need a way to present the structure of the header
and identify the fields in the uncompressed header before go detail
about how to encode it. 
The formal definition of header in our previous letter may be a good
candidate to present the structure of the header.
tcp-header := source-port
              destination-port
              ......
source-port      := bits(16)
destination-port   := bits(16)
......

Note that we may need to add some other notation to present the '|' and
'*'. We are now working on this.

> >         2. Refine the notation about FORMAT.
> > 
> > [removed to save space]
> 
> 
> Again, to summarise, we agreed that it was sensible to identify a 
> default format set to use (in the absence of any other information).
> 
> Although the index flag is in the current EPIC-lite draft it is not (I
> believe) actually necessary.  So we may be able to get rid of this. 
> However, you are right that the IR(-DYN) packets can be used 
> to select 
> the format.
> 
> I don't think that you can necessarily insist that the format only 
> changes when the state machine wants to change to IR state anyway. 
> Consider a FORMAT encoding to handle the UDP checksum.  This will have

> 2 choices 'with-checksum' and 'without-checksum'.  Now, imagine
> a UDP flow 
> changing its checksum behaviour.  (Yes, it would be weird, but...)
> It is clear that the 'with-checksum' encoding will also be able to 
> handle the 'without-checksum' case, and so the format change could be 
> deferred.  However, if the checksum starts being used on a 
> flow that is 
> using the 'without-checksum' encoding, the format transition 
> is forced 
> by the fact that it is the only way to encode the packet.
> 
> However, for the more speculative 'this format might be more efficient
> than the current one' transitions, you may well be better off waiting 
> for a natural transition to IR state...
> 

Yeah, that is the point. The state machine takes the responsibility that
decides which FORMAT should be used. When it decides that the format set
should be changed to another one, it just transits back to IR state and
initiate a procedure to make sure the decompressor uses the same format
set either.


> >     Secondly, we would like to propose some new notations for the
> > generic notation of header compression.
> > 
> 
> Now it gets interesting ;-)
>  
> > [removed to save space]
> > 
> 
> This analysis is quite thorough and correct, as far as it goes.
> However, it is clearly incorrect to say that LIST requires N*log2(N) 
> bits to encode the order data for an N-ary LIST.
> It is true that the LIST encoding will generate this many 
> bits for the 
> 'order' meta-field.  It is also true that the current set of 
> encodings 
> do not provide any obvious way of efficiently encoding the 
> LIST order. 
> Some thought leads us to recognise that the biggest problem 
> is when the 
> list is 'sparse'.  That is, there are a lot of possible 
> entries, but few 
> of them will ever actually appear in the LIST.  Sending a 
> complete order 
> for the entire list is clearly very wasteful.
> The simplest fix for this is to introduce an encoding (or set of 
> encodings?) that are capable of more efficiently representing 
> the order 
> meta-field.  For example, an encoding that sends order 
> information only 
> for those elements present in the list will be far more efficient.
> 
> Anyway, apologies for this (not so) brief digression on list order
> encoding, and back to the discussion in hand...
> 

Actually SUB-TREE-X is proposed to provide an efficient presentation for
those cases, in which there are a lot of possible entries, but few of
them will ever actually appear. We will come back to this later.

> > 
> > To propose more efficient encoding methods for
> 'out-of-order-sequence'
> > and 'repeat-sequence', we first propose an improvement on
> the compressed header format.
> > 
> > The compressed header format in EPIC-LITE divides each
> compressed header
> > into two parts: the indicator flags and the compressed fields as
> > illustrated below:
> > 
> >       +---+---+---+---+--------------------+--------------------+---
> >       | 0 | 1 | 1 | 0 | Compressed Field 1 | Compressed Field 2 |...
> >       +---+---+---+---+--------------------+--------------------+---
> >        \   \     /   /                  \     /
> >         \   \   /   /                    \   /
> >        Indicator Flags             Compressed Fields
> > 
> > Our proposed compressed header format extends it to a more general
> > format by introducing the concept of hierarchy. At the top 
> level, each
> > compressed header can be divided into also two parts: the indicator
> > flags and the (sub) compressed headers. The indicator flags 
> contain 0 or
> > more bits and specify how to decompress those (sub)
> compressed header.
> > The (sub) compressed header may be another level of
> compressed header or
> > just the compressed value of the record. The structure of
> the proposed compressed header format can be illustrated as follows:
> > 
> >    +----------------------
> >    | compressed header   ...
> >    +----------------------
> >          /       \
> >         /         \
> +-------+---------------------------+---------------------------+---
> >       | flags | (sub) compressed header 1 | (sub)
> compressed header 2 | ...
> >       
> +-------+---------------------------+---------------------------+---
> >               /       \
> >              /         \
> >        +-------------+-------------------------------+---
> >        | (sub) flags | (sub-sub) compressed header 1 | ...
> >        +-------------+-------------------------------+---
> >                        /       \
> >                       /         \
> >                             .....
> > 
> > Note that, the compressed header format in EPIC-LITE can be
> viewed as
> > the above header format with just one level, which is a
> special case of our proposed general compressed header format.
> > 
>  
> My immediate reaction to this is that it is more of an encoding rule
> issue than a notation rule issue.  (Although I'm prepared to be 
> persuaded otherwise!)  Whatever, it's an interesting thought, 
> so let's follow it...
> 


Yeah, although we are addressing the compressed header format issue, how
to encode headers really affects the notation. That is why we want to
introduce a more general structure for compressed headers.
EPIC-LITE uses only a single Huffman code to indicate the encoding
format set. However, if a type of record occurs multi-times, the profile
has to list the probability of each occurrence of the type of record.
The result is that the profile will be very large and the Huffman code
table is very large also. For 'out-of-order-sequence', order information
also needs encoding. However, if we introduce the proposed hierarchy
compressed header format, the 'repeat-sequence' and
'out-of-order-sequence' can be treated in object-oriented way. That
means records of 'repeat-sequence' and 'out-of-order-sequence' could use
sub-indicator flags to determine their own encoding methods instead of
using the top-level Huffman code. This new method will handle 'sparse'
records very efficiently.


> 
> > 
> > With the proposed compressed header format, the global 
> format set of 
> > Huffman compressed, which contains all possible combinations of 
> > compressed methods of every field,  is split into several 
> format sets 
> > which is associated with each (sub) compressed header, and 
> each format 
> > set can be tweaked into a manageable size. The complexity 
> of finding 
> > indicator flags from compressing method of each field and 
> vice versa can 
> > be alleviated in a divide-and-conquer way.
> > 
> 
> 
> I'm not sure what you mean by 'complexity' in this context?  In sheer 

Here, the complexity refers to the size of the Huffman code table, or
format sets.


> processing terms, it is clear that this approach is less 
> efficient since 
> you have to perform far more Huffman encoding/decoding operations. 
> (Method selection is still linear w.r.t. number of fields and 
> mapping to a Huffman code is near enough constant time regardless of
the 
> number of fields involved)
> 

Sub-indicator flags will be used mostly for 'out-of-order-sequence' and
'repeat-sequence', it will reduce the Huffman code table significantly.


> It is also clear that splitting the encoding up into multiple Huffman 
> codes is less efficient than treating everything as a single 
> Huffman code.
> 

Yeah, that is also a tradeoff between compression ratio and complexity.
Moreover, we want to point out that the statement given in the above may
not always hold. Suppose there are some cases that the out-of-order case
will be occurred frequently and there are a lot of possible entries with
few of them will ever actually appear. Using single Huffman code, the
order information still needs to be encoded for each field, thus it may
not efficient than just encode with sub-tree.

>  
> > 
> > For 'out-of-order-sequence' and 'repeat-sequence', we 
> propose two new 
> > encoding methods, SUB-TREE-0 and SUB-TREE-N, to handle them 
> respectively.
> >  
> > SUB-TREE-0
> > 
> > ABNF notation: "SUB-TREE-0("  "," 
> >         *("," ) ")"
> > 
> > SUB-TREE-0 encoding method tries to compress a sequence of 
> records with 
> > one ending flag. For example, tcp-options is a sequence of 
> tcp options with END as the ending flag.
> > 
> > The first parameter probability indicates how often the 
> method will be 
> > used. Note that, this probability only affects the format 
> set of the 
> > same level the SUB-TREE-0 is used, it cannot affect the 
> format set of the other levels.
> > 
> 
> 
> When you say 'how often the method will be used', are you 
> referring to 
> the SUB-TREE-0 method itself?  And, if so, what other method could be 
> given as an alternative?
> 

Yeah, the probability is used only for SUB-TREE-0 only. Would you please
explain more detail about the second question?

>  
> > 
> > The probability is followed by a set of encoding methods 
> that can be 
> > used to compress individual records in the 
> 'out-of-order-sequence'. The 
> > first  also specify the ending flag of that sequence.
> > 
> 
> 
> (A minor point, but...)  I'm not sure that the idea of specifying an 
> 'ending flag' is as flexible as the length-based approach that we 
> currently have.  For example, how would you apply this to SCTP chunk 
> headers?
> 

Great! We will add a notation SUB-TREE-LEN for this case.

SUB-TREE-LEN

ABNF notation: "SUB-TREE-LEN("  ","
 "," 
        *("," ) ")"

The 2nd parameter specifies the length of the sequence of uncompressed
records. In summary, the main difference among SUB-TREE-0, SUB-TREE-LEN,
and SUB-TREE-N is how to determine the end of the uncompressed records.
The difference is listed as follows.

SUB-TREE-0		a zero-like type of record is used to indicate
the end of the sequence of uncompressed records;
SUB-TREE-LEN	the end of the sequence of uncompressed records is
specified by the length of the uncompressed sequence;
SUB-TREE-N   	the number of the records is given somewhere;


>  
> > 
> > Using SUB-TREE-0, the order of different types of records 
> is unnecessary 
> > to encode since the compressed headers also appear in the 
> same order as 
> > the original records.  SUB-TREE-0 encoding method will 
> produce several 
> > (sub) compressed headers and generate a unique and compact 
> indicator 
> > flag for each type of record listed in the  sequence.
> > 
> 
> 
> So, are you saying that each  given as a 
> parameter to the 
> SUB-TREE-0 method is treated as a 'sub compressed-header'?
> 
> Assuming that this is the case (apologies if I've 
> mis-understood), a few questions...
> 
> - how are the sub-header indicators generated?
>    (if based on Huffman codes, where do the probabilities come from?)
> 

It can be defined as Huffman codes or not. For simple case, the
indicator flags can be index, like 0, 1, 2... If Huffman code is needed,
we can add probability for each  in the SuB-TREE-0 and
SUB-TREE-LEN notations.

> - following on, what probability would you specify for (e.g.) the 
> 'timestamp' option which, essentially, is either always 
> present or never present
> 
> - surely this is going to incur a minimum 1-bit overhead per entry in 
> the list, per packet?
> 

That is tradeoff between robustness and compression efficiency. That is,
1-bit more in each packet and good robustness (no context updating
needed) vs. occasional IR packet and not so good robustness (risk that
IR packet may be lost in the wireless link)

> 
> > 
> > SUB-TREE-N
> > 
> > ABNF notation: "SUB-TREE-N("  ","  "," 
> >  ")"
> > 
> > SUB-TREE-N encoding method try to compress a sequence of 
> the same type 
> > of records with a length field which is defined somewhere. 
> For example, 
> > CSRC list entries and SACK blocks can be used with this method. 
> > SUB-TREE-N encoding method will produce several (sub) 
> compressed headers.
> > 
> > The first parameter probability indicates how often the 
> method will be 
> > used. Note that, this probability only affects the format 
> set of the 
> > same level the SUB-TREE-N is used, it cannot affect the 
> format set of the other levels.
> > 
>  
> Same question as before regarding the  parameter.
> 
> >  
> > 
> > The second parameter specifies the maximum occurrences of 
> the type of record.
> > 
> > The third parameter is the encoding method used to compress 
> > the each record in the 'repeat-sequence'.
> > 
> 
> I feel obliged to point out that it is a trivial notational tweak to 
> introduce an encoding based on the current LIST encoding that 
> specifies a repeat of up to 'N' items...
> 

Maybe we had not explained clearly enough about SUB-TREE-N notation in
the previous email. 
SUB-TREE-N is different for the LIST with 'N' items. SUB-TREE-N uses a
length flag to indicate how many records there are and each
sub-indicator-flag for each occurrence of the type of record to specify
the encoding method for that occurrence of the type of record. However,
LIST will generate a single Huffman-code to indicate how many records
there are and encoding methods for each occurrence of the type of
record.


> 
> > Using SUB-TREE-N, the multi-occurrences don't need notating in the 
> > profile. SUB-TREE-N will produce several (sub) compressed 
> header, one of 
> > them is the number of the occurrences of the type of 
> records, others are 
> > the compressed header for each occurrence of the type of records.
> > 
> 
> 
> To pick a simple example, the CSRC list for RTP, how does this handle 
> insertion or deletion?  Imagine I have a list of 6 CSRC entries.  Now 
> imagine that an entry is inserted or deleted at index 1.  With this 
> approach, do all entries after the point of change need to be 
> re-encoded?
> 
> And, again, if a Huffman token is used for each entry, doesn't this 
> introduce a fixed minimum 1-bit overhead per entry per packet?
> 
> To re-iterate this efficiency point, one of the issues with using 
> Huffman codes is that they are maximally efficient when everything is 
> folded into the one token.  I accept that splitting the information 
> across multiple codes adds some flexibility, but it also sacrifices 
> efficiency.
> 

Yeah, however, one token of Huffman code cannot efficiently handle the
cases of 'out-of-order-sequence' and 'repeat-sequence', especially, when
they are sparse.

IMHO, as a general notation of compressed header formats, flexibility
should be one of main factors. 
Please note that SUB-TREE-* is not proposed for replacing LIST of
EPIC-LITE. Instead, it should only be used to efficiently handle sparse
'out-of-order-sequence' and 'repeat-sequence' cases.

Cheers, comments are welcome.




_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 07:40:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13378
	for ; Mon, 15 Apr 2002 07:40:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06828;
	Mon, 15 Apr 2002 07:38:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06797
	for ; Mon, 15 Apr 2002 07:38:34 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13339
	for ; Mon, 15 Apr 2002 07:38:30 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3FBcT3G002598
	for ; Mon, 15 Apr 2002 13:38:30 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 15 13:38:26 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 15 Apr 2002 13:28:00 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'rohc@ietf.org'" 
Date: Mon, 15 Apr 2002 13:37:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] Arctic ROHC web updates
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

The Arctic ROHC web page has been updated. Pages of interest for arriving participants are especially "location" and "transportation".

See U in LLA!
/Lars-Erik


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 11:05:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19923
	for ; Mon, 15 Apr 2002 11:05:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18207;
	Mon, 15 Apr 2002 10:46:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18159
	for ; Mon, 15 Apr 2002 10:46:54 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19482
	for ; Mon, 15 Apr 2002 10:46:49 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FEnTH09679
	for ; Mon, 15 Apr 2002 09:49:30 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 15 Apr 2002 09:46:49 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 15 Apr 2002 09:44:45 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 15 Apr 2002 09:44:44 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8
Thread-Index: AcHkZwDsTQcSuv4TT5OSMt0YWbtDSgAItB0g
To: , , 
X-OriginalArrivalTime: 15 Apr 2002 14:44:45.0105 (UTC) FILETIME=[158AB210:01C1E48C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA18160
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> The functionality of the STATE-FREE is: "The compressor using 
> the STATE-FREE instruction tells its remote decomressor that 
> this state will not be used anymore."

Correct.
 
> What does the decompressor do when it encounters the 
> STATE-FREE instruction?

Actually, it is the state handler that handles the request
(like the state creation request). It performs following steps:

1) check if the compressor has requested to create the 
state to be freed in the past. If not, invalid STATE_FREE,
stop.
2) deduct the size of the freed state from the state_memory
size for the compressor
3) decrement the counter associated with the freed state by 1. 
(Note, the counter of a state is incremented whenever a compressor
requests to create a state that has already been created)
4) if the counter reaches 0, physically delete the state.

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 11:12:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20057
	for ; Mon, 15 Apr 2002 11:12:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19808;
	Mon, 15 Apr 2002 11:05:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19767
	for ; Mon, 15 Apr 2002 11:05:28 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19924
	for ; Mon, 15 Apr 2002 11:05:23 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3FF5F208535;
	Mon, 15 Apr 2002 17:05:21 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: rohc@ietf.org
Cc: "Lars-Erik Jonsson (EPL)" ,
        "'Price, Richard'" ,
        "'zhigang.c.liu@nokia.com'" ,
        "Jan Christoffersson (EPL)" ,
        "Hans Hannu (EPL)" 
References: 
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 15 Apr 2002 17:05:11 +0200
In-Reply-To: 
Message-ID: 
Lines: 18
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [rohc] Re: SigComp : draft-dependency...
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

ROHCers,
sigcomp authors,

a revised issues list, together with some random comments from me, as
well as a working draft (in nroff form, with a makefile) are now at
the sigcomp CVS site,

http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/udvm/

Note that the views expressed in the issues list and the "changes"
random comments are my own, although I have stolen text liberally from
Hans' list and from mailing list comments.

I do propose that we take the resolutions indicated in the issues
list, and I also would like to resolve the issues I have marked
"further discussion required" (which should not be too hard).

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 11:24:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20342
	for ; Mon, 15 Apr 2002 11:24:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20217;
	Mon, 15 Apr 2002 11:14:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20185
	for ; Mon, 15 Apr 2002 11:14:22 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20098
	for ; Mon, 15 Apr 2002 11:14:17 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3FFE8211010;
	Mon, 15 Apr 2002 17:14:11 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Hans Hannu (EPL)" 
Cc: "'zhigang.c.liu@nokia.com'" ,
        Robert.Sugar@nokia.com, rohc@ietf.org
Subject: Re: [rohc] sigcomp issue sugar-5/cabo-8
References: 
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 15 Apr 2002 17:14:05 +0200
In-Reply-To: 
Message-ID: 
Lines: 36
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

"Hans Hannu (EPL)"  writes:

> Hi,
> 
> Just to see whether I've understood:
> 
> The functionality of the STATE-FREE is: "The compressor using the
> STATE-FREE instruction tells its remote decomressor that this state
> will not be used anymore."

... by this compressor (as identified by its session identifier on the
decompressor side).  This may be a fine point, but important.

[[There is an ugly little thing hiding here -- the compressors view of
the state memory consumed hinges on the ability of the decompressor's
application to separate sessions; the inverse is not a problem,
fortunately; so the app should err on the side of using too many
different session IDs, security permitting.  Worth noting.]]

> What does the decompressor do when it encounters the STATE-FREE instruction?
> a) It MUST delete the indicated state?
> b) It MAY delete the indicated state?

It MAY delete the state (in particular, it may be in use in another
c-d pairing = session, think "reference counting").

> One more thing.
> Should the STATE-FREE instruction also be taken to mean that: "After
> deletion of the indicate state the decompressor's allocated
> state_memory for the compressor is reduced with the size of the
> deleted state" ?

Yes (which makes the "MAY" above a bit less "MAY" and more "MUST", of
course.)

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 15 12:26:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22588
	for ; Mon, 15 Apr 2002 12:26:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24525;
	Mon, 15 Apr 2002 12:12:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24496
	for ; Mon, 15 Apr 2002 12:12:17 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22118
	for ; Mon, 15 Apr 2002 12:12:13 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4J83>; Mon, 15 Apr 2002 17:08:35 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFD6@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Hans Hannu (EPL)'" ,
        "'zhigang.c.liu@nokia.com'" ,
        Robert.Sugar@nokia.com, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
Date: Mon, 15 Apr 2002 17:08:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> Should the STATE-FREE instruction also be taken to mean that: 
> "After deletion of the indicate state the decompressor's 
> allocated state_memory for the compressor is reduced with the 
> size of the deleted state" ?

Hi,

I believe that Hans has pinpointed the key issue when discussing
the STATE-FREE instruction. We need to decide how STATE-FREE is
intended to be used so that we can determine whether it is the
best tool for the job, or whether we can provide the same
functionality more efficiently and with fewer changes to the
draft.

So far, two reasons have been mentioned as to why we might need
STATE-FREE in SigComp-06:

1. A compressor could use STATE-FREE to replace a state that it
   no longer requires with a new state.

2. A compressor could indicate that it wishes to use less memory
   than the state_memory_size it has been allocated.

Both of the above may be useful in certain scenarios, although in
each case there are alternative mechanisms that could be used to
provide the same functionality with a higher compression ratio:

We can provide the functionality of 1 by using the state priority
mechanism (possibly adding the ability to change state priorities
on the fly). The compression ratio is higher than with STATE-FREE
because it is not necessary to send a 6-byte hash to explicitly
reference a state that needs to be deleted.

We can provide the functionality of 2 by allowing the compressor
to announce exactly how much state memory it wishes to use (up to
the maximum state_memory_size imposed by the decompressor). This
saves the 6-byte hash overhead as before.

I'd be interested to hear comments on this assessment of the
situation. Do the alternatives I mentioned provide the same level
of functionality as STATE-FREE, or is there another reason that
the instruction should be included?

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 00:52:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15472
	for ; Tue, 16 Apr 2002 00:52:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06067;
	Tue, 16 Apr 2002 00:48:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06033
	for ; Tue, 16 Apr 2002 00:48:56 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15451
	for ; Tue, 16 Apr 2002 00:48:53 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3G4pYH19708
	for ; Mon, 15 Apr 2002 23:51:34 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 15 Apr 2002 23:48:54 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 15 Apr 2002 23:48:54 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 15 Apr 2002 23:48:53 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8
Thread-Index: AcHkmCdpBx4E4PKHQX2H1fFrC9/svwAV78Wg
To: , ,
        , 
X-OriginalArrivalTime: 16 Apr 2002 04:48:54.0132 (UTC) FILETIME=[02B6E340:01C1E502]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA06036
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> 1. A compressor could use STATE-FREE to replace a state that it
>    no longer requires with a new state.

STATE-FREE is simply to allow the compressor to say "I'm not going
to use a state I created before". The freed space may or may not
be used later by a new state. IMHO, STATE-FREE is simply the
natural brother of state creation, exactly like the pair we have 
for memory management: malloc() and free().
 
> 2. A compressor could indicate that it wishes to use less memory
>    than the state_memory_size it has been allocated.

I'm not sure I understand "indicate" here. STATE-FREE is not to 
"indicate". It is not about changing the state_memmory_size. 
See above.

> We can provide the functionality of 1 by using the state priority
> mechanism (possibly adding the ability to change state priorities
> on the fly). The compression ratio is higher than with STATE-FREE
> because it is not necessary to send a 6-byte hash to explicitly
> reference a state that needs to be deleted.

That's not true. As I've pointed out my previous message, you don't 
need to send the 6-byte hash explicitly for STATE-FREE either. 

> I'd be interested to hear comments on this assessment of the
> situation. Do the alternatives I mentioned provide the same level
> of functionality as STATE-FREE, or is there another reason that
> the instruction should be included?

Well, with STATE-FREE, you can do something that you cannot do
with state priority. (Namely, you can free up some memory without
having to fill it up first.) It is not true in the other direction.  
I don't see STATE-FREE is anything less than state priority. 
Given this fact, I don't understand the strong objection here to 
include STATE-FREE. Did I miss anything?

BR,
Zhigang


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 06:23:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28372
	for ; Tue, 16 Apr 2002 06:23:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02633;
	Tue, 16 Apr 2002 06:12:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02597
	for ; Tue, 16 Apr 2002 06:12:33 -0400 (EDT)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28209
	for ; Tue, 16 Apr 2002 06:12:28 -0400 (EDT)
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id g3GACT305153 for ; Tue, 16 Apr 2002 12:12:29 +0200 (CEST)
Message-ID: <006601c1e52f$bddd38e0$0701a8c0@oleane.com>
From: "Peter Lewis" 
To: 
Date: Tue, 16 Apr 2002 12:16:14 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0062_01C1E540.809C9E60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [rohc] "WLAN Security 2002" conference
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0062_01C1E540.809C9E60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The "WLAN Security 2002" conference, to take place June 25-28 in Paris, =
will feature the most eminent specialists in the domain of security =
applied to wireless local area networks.=20

The conference will serve as an occasion to clearly distinguish between =
the various technical solutions proposed today, and identify the =
weaknesses of each in terms of security: Bluetooth, IEEE802.11a/b, =
IEEE1394.=20

All details at:
http://www.upperside.fr/wlansecu/wlansecintro.htm



------=_NextPart_000_0062_01C1E540.809C9E60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable













The "WLAN Security =
2002"=20
conference, to take place June 25-28 in Paris, will feature the most =
eminent=20
specialists in the domain of security applied to wireless local area =
networks.=20


The conference will serve as an occasion to clearly distinguish =
between=20
the various technical solutions proposed today, and identify the =
weaknesses of=20
each in terms of security: Bluetooth, IEEE802.11a/b, IEEE1394. =


All=20
details at:


http://www.upp=
erside.fr/wlansecu/wlansecintro.htm


 


 


------=_NextPart_000_0062_01C1E540.809C9E60--


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 09:40:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03632
	for ; Tue, 16 Apr 2002 09:40:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15567;
	Tue, 16 Apr 2002 09:36:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15537
	for ; Tue, 16 Apr 2002 09:36:08 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03348
	for ; Tue, 16 Apr 2002 09:36:03 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4LJB>; Tue, 16 Apr 2002 14:33:27 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFDD@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'cabo@Informatik.Uni-Bremen.DE'" ,
        rohc@ietf.org
Cc: "Lars-Erik Jonsson (EPL)" ,
        "'zhigang.c.liu@nokia.com'" ,
        "Jan Christoffersson (EPL)" ,
        "Hans Hannu (EPL)" 
Date: Tue, 16 Apr 2002 14:33:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: [rohc] sigcomp issue lejo-8
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> Strange UDVM lifetime
>
> Why is the UDVM kept alive during the application decision to supply a
> compartment ID?
>
> This defines a protracted multi-step interface, which tends
> to unnecessarily extend the UDVM lifetime.  While all this is a local
> implementation issue, the text should not give the impression the UDVM
> (and its memory) needs to be around longer than during its own runtime.

Hi,

The UDVM memory does need to be around until the session ID is returned
by the application. The state item that the UDVM wants to create needs to
be stored somewhere, and for simple algorithms (certainly all that I've
written so far) the state item is around 95% of the total UDVM memory.

We can't free up the per-message memory until a session ID is returned
(at which point we can use the per-session memory instead).

Regards,

Richard

P.S. I suppose that advanced implementations might be able to reclaim
part of the UDVM memory before the session ID is returned (namely whatever
is not being used to store the state item). However I think this will be
an obvious step for anyone writing a heavily optimized UDVM.

> -----Original Message-----
> From: cabo@Informatik.Uni-Bremen.DE
> [mailto:cabo@Informatik.Uni-Bremen.DE]
> Sent: Monday, April 15, 2002 4:05 PM
> To: rohc@ietf.org
> Cc: Lars-Erik Jonsson (EPL); Price, Richard; 
> 'zhigang.c.liu@nokia.com';
> Jan Christoffersson (EPL); Hans Hannu (EPL)
> Subject: Re: SigComp : draft-dependency...
> 
> 
> ROHCers,
> sigcomp authors,
> 
> a revised issues list, together with some random comments from me, as
> well as a working draft (in nroff form, with a makefile) are now at
> the sigcomp CVS site,
> 
> http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/udvm/
> 
> Note that the views expressed in the issues list and the "changes"
> random comments are my own, although I have stolen text liberally from
> Hans' list and from mailing list comments.
> 
> I do propose that we take the resolutions indicated in the issues
> list, and I also would like to resolve the issues I have marked
> "further discussion required" (which should not be too hard).
> 
> Gruesse, Carsten
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 09:56:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04479
	for ; Tue, 16 Apr 2002 09:56:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16364;
	Tue, 16 Apr 2002 09:47:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16331
	for ; Tue, 16 Apr 2002 09:47:33 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03969
	for ; Tue, 16 Apr 2002 09:47:24 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3GDlII24067;
	Tue, 16 Apr 2002 15:47:22 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Price, Richard" 
Cc: rohc@ietf.org,
        "Lars-Erik Jonsson (EPL)" ,
        "'zhigang.c.liu@nokia.com'" ,
        "Jan Christoffersson (EPL)" ,
        "Hans Hannu (EPL)" 
Subject: Re: [rohc] sigcomp issue lejo-8
References: <76C92FBBFB58D411AE760090271ED41804A0EFDD@rsys002a.roke.co.uk>
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 16 Apr 2002 15:47:15 +0200
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0EFDD@rsys002a.roke.co.uk>
Message-ID: 
Lines: 16
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

"Price, Richard"  writes:

> The UDVM memory does need to be around until the session ID is returned
> by the application. The state item that the UDVM wants to create needs to
> be stored somewhere, and for simple algorithms (certainly all that I've
> written so far) the state item is around 95% of the total UDVM memory.

My (possibly slightly more abstract) mental model is that the output
message plus the parameters of the END-MESSAGE stay around while the
app is interrogated.  Not the UDVM.

Now, as an optimization, you may want to keep the UDVM core around to
avoid the copying, but I would not want that optimization in the
model.  In the model, the UDVM dies with END-MESSAGE.

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 11:28:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08195
	for ; Tue, 16 Apr 2002 11:28:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22619;
	Tue, 16 Apr 2002 11:15:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22586
	for ; Tue, 16 Apr 2002 11:15:25 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07681
	for ; Tue, 16 Apr 2002 11:15:19 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GFFL3G013787
	for ; Tue, 16 Apr 2002 17:15:21 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 17:15:16 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 16 Apr 2002 17:04:49 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Date: Tue, 16 Apr 2002 17:14:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] sigcomp issue lejo-10
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> Security implications???

The feedback data is not to be passed to the compressor unless a valid session ID is presented. To my knowledge that is no difference from what is in SigComp-05.

> What would be the meaning of I=0?
> The receiver dumping all its locally available state (i.e., lots)?
> There must be a somewhat more useful definition, giving the receiver
> some leeway in deciding what to do with this request.

The I-bit can be used by an endpoint to indicate to its remote endpoint that it is not interested in receiving a list of locally available states. This would be indicated by setting the I-bit. 
If the I-bit is zero, it is up to the receiving endpoint to decide whether it should send a list of locally available states. 

This is the same as with the announcement information that we had in SigComp-05, except that now there is also a possibility for a compressor to say that it does not wish to receive this kind of announcement.

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 12:06:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12230
	for ; Tue, 16 Apr 2002 12:06:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24646;
	Tue, 16 Apr 2002 11:54:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24615
	for ; Tue, 16 Apr 2002 11:54:01 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10028
	for ; Tue, 16 Apr 2002 11:53:55 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3GFsEF27250
	for ; Tue, 16 Apr 2002 18:54:14 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 16 Apr 2002 18:53:56 +0300
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 16 Apr 2002 18:53:56 +0300
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 16 Apr 2002 10:53:54 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue lejo-8
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 16 Apr 2002 10:53:53 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-8
Thread-Index: AcHlTVVK3W8F60vdSYeI4jejonXVEAADc8Ow
To: , 
Cc: , ,
        , 
X-OriginalArrivalTime: 16 Apr 2002 15:53:54.0337 (UTC) FILETIME=[E9170110:01C1E55E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA24616
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> "Price, Richard"  writes:
> 
> > The UDVM memory does need to be around until the session ID 
> is returned
> > by the application. The state item that the UDVM wants to 
> create needs to
> > be stored somewhere, and for simple algorithms (certainly 
> all that I've
> > written so far) the state item is around 95% of the total 
> UDVM memory.

[Carsten wrote:]
 
> My (possibly slightly more abstract) mental model is that the output
> message plus the parameters of the END-MESSAGE stay around while the
> app is interrogated.  Not the UDVM.
> 
> Now, as an optimization, you may want to keep the UDVM core around to
> avoid the copying, but I would not want that optimization in the
> model.  In the model, the UDVM dies with END-MESSAGE.

I agree with Carsten. Call me a purist if you like. :-) 

Re the copying, you only save it if the message is rejected by app.
For an accepted message, you have to copy those stuff (e.g. states)
at least once from UDVM bytebuffer to outside UDVM. Then, if you
can avoid moving them around afterwards (easy for states, they
can be anywhere in state handler as long as you hold the pointers),
there is no additional cost even in the "pure" model.

Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 13:07:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20604
	for ; Tue, 16 Apr 2002 13:07:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29323;
	Tue, 16 Apr 2002 12:58:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29292
	for ; Tue, 16 Apr 2002 12:58:40 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19316
	for ; Tue, 16 Apr 2002 12:58:38 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4LYR>; Tue, 16 Apr 2002 17:54:48 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE1@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        cabo@Informatik.Uni-Bremen.DE
Cc: rohc@ietf.org, Lars-Erik.Jonsson@epl.ericsson.se,
        Jan.Christoffersson@epl.ericsson.se, Hans.Hannu@epl.ericsson.se
Subject: RE: [rohc] sigcomp issue lejo-8
Date: Tue, 16 Apr 2002 17:54:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > My (possibly slightly more abstract) mental model is that the output
> > message plus the parameters of the END-MESSAGE stay around while the
> > app is interrogated.  Not the UDVM.

Hi,

I have a somewhat different mental model of SigComp. In my own model I
believe that each piece of information required by SigComp should have a
logical entity that stores this information. I think that this is nice
for keeping the architecture "pure", and also useful when considering the
security implications of SigComp.

The newly requested state item shouldn't be kept by the decompressor
dispatcher, because the responsibility of this entity is simply to provide
an interface between the UDVM (which is protocol-independent) and the
particular application and transport that are currently in use.

Also the state item shouldn't be given to the state handler until the
session ID is available because (in my opinion) the state handler only
cares about sessions and not messages. In particular it only stores per-
session data and not per-message data.

Rather than invent a completely new logical entity to store the item of
state before it is created, I prefer to think of the UDVM as remaining
open until the session ID has been provided.

> > Now, as an optimization, you may want to keep the UDVM core around to
> > avoid the copying, but I would not want that optimization in the
> > model.  In the model, the UDVM dies with END-MESSAGE.
> 
> I agree with Carsten. Call me a purist if you like. :-) 

As a pure mathematician, I'll always choose the "purest" mental model over
the easiest model to implement. The fact that my own mental picture of
SigComp seems to coincide with how it would actually be implemented is
something of a minor miracle - as Mark West will no doubt confirm this
has never happened before and will almost certainly never happen again...

> Re the copying, you only save it if the message is rejected by app.
> For an accepted message, you have to copy those stuff (e.g. states)
> at least once from UDVM bytebuffer to outside UDVM. Then, if you
> can avoid moving them around afterwards (easy for states, they
> can be anywhere in state handler as long as you hold the pointers),
> there is no additional cost even in the "pure" model.

From an implementation perspective the mental model we each choose to
adopt isn't important. I prefer the UDVM to hold a pending state
creation request because I believe that it is "purer" than giving the
state to the state handler (or storing it in limbo) before it has been
accepted by the application.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 13:10:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20921
	for ; Tue, 16 Apr 2002 13:10:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00224;
	Tue, 16 Apr 2002 13:08:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00187
	for ; Tue, 16 Apr 2002 13:08:46 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20713
	for ; Tue, 16 Apr 2002 13:08:43 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GH8is7029288
	for ; Tue, 16 Apr 2002 19:08:44 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 19:08:42 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 16 Apr 2002 18:58:15 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Date: Tue, 16 Apr 2002 19:08:22 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] sigcomp issue rp-8
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

My thoughts on the STATE-CREATE instruction.

> I'm not so sure. Allowing to create a few small states is sometime 
> convenient for a compressor to avoid overlapping between large 
> states. It also gives the compressor more control on the memory
> management.

You could avoid overlapping between states already with the current set of instructions namely the END-MESSAGE instruction and the STATE-ACCESS instruction. 
- You have the possibility to instruct on what data to create a state (END-MESSAGE instruction). 
- With the STATE-ACCESS instruction it is possible to access any octet string from different states. 

On the other hand this instruction fits very well with the state_retention_priority as parts of the UDVM memory saved as states can be assigned different deletion priorities, which may give the compressor more control on the memory management.

On the third hand after reading the emails regarding sigcomp issue lejo-8 the STATE-CREATE instruction may imply additional efforts as the UDVM may hold several pending state creation requests instead of just a maximum of one.

BR
/Hans H


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 13:24:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22379
	for ; Tue, 16 Apr 2002 13:24:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00539;
	Tue, 16 Apr 2002 13:19:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00512
	for ; Tue, 16 Apr 2002 13:18:59 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21862
	for ; Tue, 16 Apr 2002 13:18:53 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GHIss7000589
	for ; Tue, 16 Apr 2002 19:18:54 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 16 19:20:46 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 16 Apr 2002 19:08:26 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Date: Tue, 16 Apr 2002 19:18:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] sigcomp issue cabo-11
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

> It would be possible to put the message size in low memory,
> as we do with state_length.

> Action

> (decide whether to use low memory)

Would the suggested action cause any problems? 
If not why not just go ahead and use the lower memory if that would avoid a loop.

BR
/Hans H

 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 13:44:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24930
	for ; Tue, 16 Apr 2002 13:44:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02058;
	Tue, 16 Apr 2002 13:40:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02022
	for ; Tue, 16 Apr 2002 13:40:11 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24476
	for ; Tue, 16 Apr 2002 13:40:08 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GHe9s7003171
	for ; Tue, 16 Apr 2002 19:40:09 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 19:40:09 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTMT61>; Tue, 16 Apr 2002 19:40:09 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
Date: Tue, 16 Apr 2002 19:39:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


[Zhigang wrote:]
> STATE-FREE is simply to allow the compressor to say "I'm not going
> to use a state I created before". The freed space may or may not
> be used later by a new state. 
...
> Well, with STATE-FREE, you can do something that you cannot do
> with state priority. (Namely, you can free up some memory without
> having to fill it up first.) 

Ok.

So my question is now do we need to specify what a reciever of a STATE-FREE request should do with this knowledge?
-If it does not affect the compressor in any way then I think not.
I.e. as Carsten put it "It MAY delete the state (in particular, it may be in use in another
c-d pairing = session, think "reference counting")".

BR
/Hans H 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 14:07:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27627
	for ; Tue, 16 Apr 2002 14:07:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03716;
	Tue, 16 Apr 2002 14:01:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03673
	for ; Tue, 16 Apr 2002 14:01:55 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27089
	for ; Tue, 16 Apr 2002 14:01:51 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GI1qs7005202
	for ; Tue, 16 Apr 2002 20:01:52 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 16 20:03:44 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTM4DB>; Tue, 16 Apr 2002 20:01:52 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Date: Tue, 16 Apr 2002 20:01:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] sigcomp issue cabo-6
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

> The original idea in the proposed resolution was to be able to put the
> code behind all the data.  This is no longer possible. Bug/Feature?

Why is this not possible? 
To me the SigComp-05a approach and the approach in the issues list are similar except in the way the code start address is worked out.

SigComp-05a: code start address equals: the destination field * 64.
Issues list: code start address equals: 2^(destination field?) - code length.

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 14:26:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29599
	for ; Tue, 16 Apr 2002 14:26:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04819;
	Tue, 16 Apr 2002 14:20:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04786
	for ; Tue, 16 Apr 2002 14:20:15 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28949
	for ; Tue, 16 Apr 2002 14:20:11 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GIKCs7007123
	for ; Tue, 16 Apr 2002 20:20:12 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 20:20:11 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 16 Apr 2002 20:09:44 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Date: Tue, 16 Apr 2002 20:19:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] sigcomp issue cabo-15
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

> decompression_memory_size differs from the proposed resolution,
> though (maybe I just don't understand 3.3.1; it's certainly not
> crystal clear).

My understanding is that decompression_memory_size, includes the former parameters "compressed-message-size" and "UDVM-memory-size" which would correspond to a input buffer and the UDVM byte-buffer (UDVM memory). So the only thing this excludes is the former parameter "decompressed-message-size". However, that could also bundle up with the others into the decompression_memory_size, by adding some text to section 3.3.1.

"The decompression_memory_size parameter specifies the amount of 
   memory available to decompress one SigComp message. A portion of this 
   memory is used to buffer a SigComp message before *and after* it is decompressed; 
   the remainder is given to the UDVM..."

> cycles_per_bit can only be 16 to 128; I believe lower values are
> required.  (And the default may need to be lower: As it stands, 12000
> bit messages can use up to 208000 cycles, that is quite a lot,
> considering that many server-side implementations may need a few
> hundred ns per cycle, and UE implementations easily can take several
> us.)

Hmm, what is a reasonable value for a deflate algorithm, with a compressed message of say 12000 bits?

BR
/Hans H 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 14:56:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03513
	for ; Tue, 16 Apr 2002 14:56:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06770;
	Tue, 16 Apr 2002 14:51:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06733
	for ; Tue, 16 Apr 2002 14:51:14 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02656
	for ; Tue, 16 Apr 2002 14:51:08 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GIp9s7010386
	for ; Tue, 16 Apr 2002 20:51:09 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 20:51:08 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTM4XV>; Tue, 16 Apr 2002 20:51:09 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Date: Tue, 16 Apr 2002 20:50:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] sigcomp issue sugar-6
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> However, at a
> pinch the S-bit can be sent at the end of a session to indicate
> explicitly that the session has closed and the memory used by the
> session state can be reclaimed.

To me this make the STATE-FLUSH instruction unnecessary. However, we need to clarify that the setting of the S-bit in the middle of a SigComp session would have this effect.

I do not see that the S-bit would raise any additional security risks.

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 17:29:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22352
	for ; Tue, 16 Apr 2002 17:29:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15508;
	Tue, 16 Apr 2002 17:25:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15475
	for ; Tue, 16 Apr 2002 17:25:18 -0400 (EDT)
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21849
	for ; Tue, 16 Apr 2002 17:25:13 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3GLQHJ07303
	for ; Wed, 17 Apr 2002 00:26:17 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 17 Apr 2002 00:25:13 +0300
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 00:25:12 +0300
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 16 Apr 2002 16:24:02 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue lejo-10
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 16 Apr 2002 16:24:02 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-10
Thread-Index: AcHlWaLnaIsXFgj+Qo2TjkRNBns6pQAKNB8A
To: , 
X-OriginalArrivalTime: 16 Apr 2002 21:24:02.0917 (UTC) FILETIME=[07EC7150:01C1E58D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA15476
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> The I-bit can be used by an endpoint to indicate to its 
> remote endpoint that it is not interested in receiving a list 
> of locally available states. This would be indicated by 
> setting the I-bit. 
> If the I-bit is zero, it is up to the receiving endpoint to 
> decide whether it should send a list of locally available states. 

Just one editorial comment. Should we add specifications on
the receiver behavior as follows?

"If I-bit is set to zero, the receiving endpoint MUST NOT return 
the list of locally available state items. Otherwise, it SHOULD
return the list. "

Same comment goes to S-bit.

Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 18:18:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27754
	for ; Tue, 16 Apr 2002 18:18:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17708;
	Tue, 16 Apr 2002 18:17:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17672
	for ; Tue, 16 Apr 2002 18:17:08 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27585
	for ; Tue, 16 Apr 2002 18:17:03 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3GMHRs28390
	for ; Tue, 16 Apr 2002 17:17:27 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 16 Apr 2002 17:17:06 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 16 Apr 2002 17:17:06 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue cabo-11
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 16 Apr 2002 17:17:05 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-11
Thread-Index: AcHlauGfqlTiVUcYQzq7xO4OuukGbQAJrC2w
To: , 
X-OriginalArrivalTime: 16 Apr 2002 22:17:06.0097 (UTC) FILETIME=[713F2A10:01C1E594]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA17676
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> > It would be possible to put the message size in low memory,
> > as we do with state_length.
> 
> > Action
> 
> > (decide whether to use low memory)

[Hans wrote:]
 
> Would the suggested action cause any problems? 
> If not why not just go ahead and use the lower memory if that 
> would avoid a loop.

I would suggest to go this way too. The only implication is that 
the decompressor dispatcher needs to have a complete SigComp 
message before invoking UDVM. But that is not a problem to me.

Also, the definition of INPUT-BYTECODE is unclear about the
case of length == 0. I proposed to use length zero to indicate
"I want all the rest of the message". But that is moot if we
put message size in low memory. Then, we could clarify 
zero length case by replacing fourth paragraph of section 
9.4.2 as follows:

"If the instruction requests data that lies beyond the end of the
SigComp message or the requested data length equals zero, no data 
is returned. Instead the UDVM moves program execution to the 
address specified by the address operand."

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 19:36:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05055
	for ; Tue, 16 Apr 2002 19:36:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20834;
	Tue, 16 Apr 2002 19:31:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20802
	for ; Tue, 16 Apr 2002 19:31:46 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04642
	for ; Tue, 16 Apr 2002 19:31:42 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3GNVYI18821;
	Wed, 17 Apr 2002 01:31:38 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: zhigang.c.liu@nokia.com
Cc: , 
Subject: Re: [rohc] sigcomp issue cabo-11
References: 
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 17 Apr 2002 01:31:32 +0200
In-Reply-To: 
Message-ID: 
Lines: 68
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

zhigang.c.liu@nokia.com writes:

> > > It would be possible to put the message size in low memory,
> > > as we do with state_length.
> >
> > > Action
> >
> > > (decide whether to use low memory)
>
> [Hans wrote:]
>
> > Would the suggested action cause any problems?
> > If not why not just go ahead and use the lower memory if that
> > would avoid a loop.
>
> I would suggest to go this way too. The only implication is that
> the decompressor dispatcher needs to have a complete SigComp
> message before invoking UDVM. But that is not a problem to me.

Yes (sorry, I considered but failed to document this implication).

It's not a problem for me, either.
(It does remove some implementation flexibility for the TCP case,
though.)

Actually, I believe all remnants of text about UDVMs staying active
while waiting for external events should be removed from the document.
(Ceterum censeo...)

> Also, the definition of INPUT-BYTECODE is unclear about the
> case of length == 0.

No, I believe it's perfectly clear.  As requested, you get zero bytes
copied.  The operation succeeds (i.e., does not jump to @address), as
no data beyond the input message was requested.

> I proposed to use length zero to indicate
> "I want all the rest of the message". But that is moot if we
> put message size in low memory.

Exactly.

The low memory approach also would allow the decompressor code to
"plan" for the size of the input message before sucking it in.

> Then, we could clarify
> zero length case by replacing fourth paragraph of section
> 9.4.2 as follows:
>
> "If the instruction requests data that lies beyond the end of the
> SigComp message or the requested data length equals zero, no data
> is returned. Instead the UDVM moves program execution to the
> address specified by the address operand."

That would be an unnecessary change (why put in a special case to fail
on 0?).

(Generally, giving special meanings to special values of arguments for
an operation generates trouble.  Making the change might mean that a
decompressor must check a length of additional data it has computed
for zero to avoid accidentally terminating when no additional data is
needed.)

Gruesse, Carsten

PS.: Oh, the name INPUT-BYTECODE has become quite misleading now.
How about INPUT-BYTES?
(Or INPUT-OCTETS, if it must be :-)


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 16 20:33:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11568
	for ; Tue, 16 Apr 2002 20:33:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22461;
	Tue, 16 Apr 2002 20:26:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22428
	for ; Tue, 16 Apr 2002 20:26:54 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10645
	for ; Tue, 16 Apr 2002 20:26:50 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H0TUH06675
	for ; Tue, 16 Apr 2002 19:29:30 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 16 Apr 2002 19:26:50 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 16 Apr 2002 19:25:48 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue lejo-8
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 16 Apr 2002 19:25:48 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-8
Thread-Index: AcHlZ6A5A0pyayu/RbKS1rw9qiI2iQANeaCQ
To: , 
Cc: , ,
        , 
X-OriginalArrivalTime: 17 Apr 2002 00:25:48.0415 (UTC) FILETIME=[6C1B60F0:01C1E5A6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA22429
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

(All right, it is clearly my mistake to mention the word "pure". I
should have known that. )

Going back to the issue, can we agree on the following?

a) optimization is not the reason for choosing one over the other. 

b) the reason we have UDVM is to support different decompression 
algorithms without negotiation. Nothing more than that. Its minimal
job is to decompress and interpret state creation requests. Whether 
one wants to put more functions to UDVM is an implementation issue. 
Therefore, the text should not dictate either way.

(To me, keeping UDVM lifetime shorter simplifies interfaces. But
others may want to implement differently.  )

BR,
Zhigang

> -----Original Message-----
> From: ext Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: April 16, 2002 11:55 AM
> To: Liu Zhigang.C (NRC/Dallas); cabo@Informatik.Uni-Bremen.DE
> Cc: rohc@ietf.org; Lars-Erik.Jonsson@epl.ericsson.se;
> Jan.Christoffersson@epl.ericsson.se; Hans.Hannu@epl.ericsson.se
> Subject: RE: [rohc] sigcomp issue lejo-8
> 
> 
> > > My (possibly slightly more abstract) mental model is that 
> the output
> > > message plus the parameters of the END-MESSAGE stay 
> around while the
> > > app is interrogated.  Not the UDVM.
> 
> Hi,
> 
> I have a somewhat different mental model of SigComp. In my own model I
> believe that each piece of information required by SigComp 
> should have a
> logical entity that stores this information. I think that this is nice
> for keeping the architecture "pure", and also useful when 
> considering the
> security implications of SigComp.
> 
> The newly requested state item shouldn't be kept by the decompressor
> dispatcher, because the responsibility of this entity is 
> simply to provide
> an interface between the UDVM (which is protocol-independent) and the
> particular application and transport that are currently in use.
> 
> Also the state item shouldn't be given to the state handler until the
> session ID is available because (in my opinion) the state handler only
> cares about sessions and not messages. In particular it only 
> stores per-
> session data and not per-message data.
> 
> Rather than invent a completely new logical entity to store 
> the item of
> state before it is created, I prefer to think of the UDVM as remaining
> open until the session ID has been provided.
> 
> > > Now, as an optimization, you may want to keep the UDVM 
> core around to
> > > avoid the copying, but I would not want that optimization in the
> > > model.  In the model, the UDVM dies with END-MESSAGE.
> > 
> > I agree with Carsten. Call me a purist if you like. :-) 
> 
> As a pure mathematician, I'll always choose the "purest" 
> mental model over
> the easiest model to implement. The fact that my own mental picture of
> SigComp seems to coincide with how it would actually be implemented is
> something of a minor miracle - as Mark West will no doubt confirm this
> has never happened before and will almost certainly never 
> happen again...
> 
> > Re the copying, you only save it if the message is rejected by app.
> > For an accepted message, you have to copy those stuff (e.g. states)
> > at least once from UDVM bytebuffer to outside UDVM. Then, if you
> > can avoid moving them around afterwards (easy for states, they
> > can be anywhere in state handler as long as you hold the pointers),
> > there is no additional cost even in the "pure" model.
> 
> From an implementation perspective the mental model we each choose to
> adopt isn't important. I prefer the UDVM to hold a pending state
> creation request because I believe that it is "purer" than giving the
> state to the state handler (or storing it in limbo) before it has been
> accepted by the application.
> 
> Regards,
> 
> Richard
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 00:20:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01597
	for ; Wed, 17 Apr 2002 00:20:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02517;
	Wed, 17 Apr 2002 00:16:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02442
	for ; Wed, 17 Apr 2002 00:16:36 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01580
	for ; Wed, 17 Apr 2002 00:16:34 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H4JFH13642
	for ; Tue, 16 Apr 2002 23:19:15 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 16 Apr 2002 23:16:35 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 16 Apr 2002 23:15:10 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue rp-8
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 16 Apr 2002 23:15:10 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue rp-8
Thread-Index: AcHlbGcYCdCCgk/vT1yExb1WWmgiCwATi6fQ
To: , 
X-OriginalArrivalTime: 17 Apr 2002 04:15:10.0747 (UTC) FILETIME=[771896B0:01C1E5C6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA02460
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: ext Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se]
> Sent: April 16, 2002 12:08 PM
> To: 'rohc@ietf.org'
> Subject: [rohc] sigcomp issue rp-8
> 
> 
> Hi,
> 
> My thoughts on the STATE-CREATE instruction.
> 
> > I'm not so sure. Allowing to create a few small states is sometime 
> > convenient for a compressor to avoid overlapping between large 
> > states. It also gives the compressor more control on the memory
> > management.
> 
> You could avoid overlapping between states already with the 
> current set of instructions namely the END-MESSAGE 
> instruction and the STATE-ACCESS instruction. 
> - You have the possibility to instruct on what data to create 
> a state (END-MESSAGE instruction). 
> - With the STATE-ACCESS instruction it is possible to access 
> any octet string from different states. 

Right.

> On the other hand this instruction fits very well with the 
> state_retention_priority as parts of the UDVM memory saved as 
> states can be assigned different deletion priorities, which 
> may give the compressor more control on the memory management.

Smaller states give you finer granularity.

> On the third hand after reading the emails regarding sigcomp 
> issue lejo-8 the STATE-CREATE instruction may imply 
> additional efforts as the UDVM may hold several pending state 
> creation requests instead of just a maximum of one.

We can have say 3 or 4 as the maximum # of state creation requests 
per message. That gives enough flexibility and yet won't create trouble: 
you still authenticate the decompressed message only once. 

Zhigang


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 01:10:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01598
	for ; Wed, 17 Apr 2002 00:20:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02509;
	Wed, 17 Apr 2002 00:16:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02452
	for ; Wed, 17 Apr 2002 00:16:40 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01583
	for ; Wed, 17 Apr 2002 00:16:38 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3H4JJH13682
	for ; Tue, 16 Apr 2002 23:19:19 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 16 Apr 2002 23:16:36 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 16 Apr 2002 23:15:12 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 16 Apr 2002 23:15:11 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8
Thread-Index: AcHlbdVcFVR+9B8WS0OnH0n9Z9tr9QAT6nHQ
To: , 
X-OriginalArrivalTime: 17 Apr 2002 04:15:12.0060 (UTC) FILETIME=[77E0EFC0:01C1E5C6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA02453
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> So my question is now do we need to specify what a reciever 
> of a STATE-FREE request should do with this knowledge?
> -If it does not affect the compressor in any way then I think not.
> I.e. as Carsten put it "It MAY delete the state (in 
> particular, it may be in use in another
> c-d pairing = session, think "reference counting")".

I answered this question in my email yesterday (see below). By
"reference counting", Carsten referst to the case where a compressor
request to create a state that already exists. It's a term
used in OOP to determin when a shared object can be safely physically
deleted.

(Note there is actually step 0 which is to authenticate the message
and find out which compressor sends the request. I omitted it as
it is common to a state creation request.)

BR,
Zhigang

----------------------
Actually, it is the state handler that handles the request
(like the state creation request). It performs following steps:

1) check if the compressor has requested to create the 
state to be freed in the past. If not, invalid STATE_FREE,
stop.
2) deduct the size of the freed state from the state_memory
size for the compressor
3) decrement the counter associated with the freed state by 1. 
(Note, the counter of a state is incremented whenever a compressor
requests to create a state that has already been created)
4) if the counter reaches 0, physically delete the state.
----------------------

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 03:38:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11902
	for ; Wed, 17 Apr 2002 03:38:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21549;
	Wed, 17 Apr 2002 03:30:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21518
	for ; Wed, 17 Apr 2002 03:30:31 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11815
	for ; Wed, 17 Apr 2002 03:30:27 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3H7UT3G024386
	for ; Wed, 17 Apr 2002 09:30:29 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Apr 17 09:29:30 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 17 Apr 2002 09:19:03 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'cabo@Informatik.Uni-Bremen.DE'" ,
        zhigang.c.liu@nokia.com
Cc: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-11
Date: Wed, 17 Apr 2002 09:28:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> Actually, I believe all remnants of text about UDVMs staying active
> while waiting for external events should be removed from the document.
> (Ceterum censeo...)

Does this imply anything to the "SigComp solution" or is the current text regarding this (see also sigcomp issue lejo-8) just there to optimise implementations?

> PS.: Oh, the name INPUT-BYTECODE has become quite misleading now.
> How about INPUT-BYTES?
> (Or INPUT-OCTETS, if it must be :-)

I think INPUT-OCTETS would be clearer.

BR
/Hans H
 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 03:52:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12136
	for ; Wed, 17 Apr 2002 03:52:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22081;
	Wed, 17 Apr 2002 03:39:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22045
	for ; Wed, 17 Apr 2002 03:39:44 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11931
	for ; Wed, 17 Apr 2002 03:39:40 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3H7dgs7020960
	for ; Wed, 17 Apr 2002 09:39:42 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 17 09:39:14 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 17 Apr 2002 09:28:46 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 09:37:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> Just one editorial comment. Should we add specifications on
> the receiver behavior as follows?
> 
> "If I-bit is set to zero, the receiving endpoint MUST NOT return 
> the list of locally available state items. Otherwise, it SHOULD
> return the list. "
> 
> Same comment goes to S-bit.

I do not think it is necessary, SigComp would not crash if it receives this kind of information although it is unwanted. I think the current text should be enough motivation for not sending the list if the I-bit is set.

Section 9.4.7
"...This can help to conserve bandwidth by avoiding..."

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 07:18:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14509
	for ; Wed, 17 Apr 2002 07:18:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02067;
	Wed, 17 Apr 2002 07:11:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02026
	for ; Wed, 17 Apr 2002 07:11:44 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14421
	for ; Wed, 17 Apr 2002 07:11:41 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4MXS>; Wed, 17 Apr 2002 12:04:46 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE2@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'cabo@Informatik.Uni-Bremen.DE'" ,
        zhigang.c.liu@nokia.com
Cc: Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-11
Date: Wed, 17 Apr 2002 12:04:38 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > > Would the suggested action cause any problems?
> > > If not why not just go ahead and use the lower memory if that
> > > would avoid a loop.
> >
> > I would suggest to go this way too. The only implication is that
> > the decompressor dispatcher needs to have a complete SigComp
> > message before invoking UDVM. But that is not a problem to me.
> 
> Yes (sorry, I considered but failed to document this implication).
> 
> It's not a problem for me, either.
> (It does remove some implementation flexibility for the TCP case,
> though.)

Hi,

The TCP case is something that hasn't received enough discussion on the
mailing list - so I've attempted to explain the two ways that we could
support TCP and why SigComp uses the more complex approach:

The simplest way to support TCP would be to just rely on the message
delimiters to convert a TCP stream into a series of distinct, bounded
messages. The receiving endpoint could then input an entire message
before it is decompressed.

The alternative approach is to allow the receiving endpoint to stream-
decompress a SigComp message (i.e. to input, decompress and output the
first part of a SigComp message before the remainder of the message has
even arrived). This is the approach currently used by SigComp (we first
took the simple approach but then changed to stream decompression in
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-udvm-00.txt).

The first approach is certainly simpler, but the second approach offers
significantly better performance because it takes into account the way
signalling applications make use of TCP.

In SIP for example, TCP support is provided to ensure that SIP can cope
with large application messages. It is mandatory to transport messages
larger than 1300 bytes using TCP (assuming an MTU of 1500 bytes), so
that fragmentation can be avoided.

If we need to buffer all SigComp messages before they are decompressed
then enough memory will need to be provided to meet the worst-case
message size (including the large messages that are sent over TCP).
This could be anything up to 64K.

However, if we can stream-decompress a SigComp message sent over TCP
then there is no need to buffer the entire message while it is being
decompressed. This means that we only need to provide a SigComp input
buffer large enough to cope with messages sent over UDP.

Another advantage of allowing SigComp messages to be stream-decompressed
is that the application may rely on the underlying transport to provide
security (e.g. TLS). In this case the application may wish to avoid the
overhead of using state identifiers and message delimiters (which are
unnecessary over TLS), opting instead to treat the entire TLS stream as
a single SigComp message. This approach saves at least 10 bytes per
application message when running over a secure transport.

> Actually, I believe all remnants of text about UDVMs staying active
> while waiting for external events should be removed from the document.
> (Ceterum censeo...)

If we allow stream decompression to take place then it's important to
allow the UDVM to request more input and pause until the input is
received. I can't see any way to avoid this.

> > Also, the definition of INPUT-BYTECODE is unclear about the
> > case of length == 0.
> 
> No, I believe it's perfectly clear.  As requested, you get zero bytes
> copied.  The operation succeeds (i.e., does not jump to @address), as
> no data beyond the input message was requested.
> 
> > I proposed to use length zero to indicate
> > "I want all the rest of the message". But that is moot if we
> > put message size in low memory.
> 
> Exactly.
> 
> The low memory approach also would allow the decompressor code to
> "plan" for the size of the input message before sucking it in.
> 
> > Then, we could clarify
> > zero length case by replacing fourth paragraph of section
> > 9.4.2 as follows:
> >
> > "If the instruction requests data that lies beyond the end of the
> > SigComp message or the requested data length equals zero, no data
> > is returned. Instead the UDVM moves program execution to the
> > address specified by the address operand."
> 
> That would be an unnecessary change (why put in a special case to fail
> on 0?).
> 
> (Generally, giving special meanings to special values of arguments for
> an operation generates trouble.  Making the change might mean that a
> decompressor must check a length of additional data it has computed
> for zero to avoid accidentally terminating when no additional data is
> needed.)
> 
> Gruesse, Carsten
> 
> PS.: Oh, the name INPUT-BYTECODE has become quite misleading now.
> How about INPUT-BYTES?
> (Or INPUT-OCTETS, if it must be :-)

Ok, let's make this change. Bytes and octets are both fine by me.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 08:30:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15671
	for ; Wed, 17 Apr 2002 08:30:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05222;
	Wed, 17 Apr 2002 08:21:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05193
	for ; Wed, 17 Apr 2002 08:21:05 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15471
	for ; Wed, 17 Apr 2002 08:21:02 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4M7Q>; Wed, 17 Apr 2002 13:17:22 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE3@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        cabo@Informatik.Uni-Bremen.DE
Cc: rohc@ietf.org, Lars-Erik.Jonsson@epl.ericsson.se,
        Jan.Christoffersson@epl.ericsson.se, Hans.Hannu@epl.ericsson.se
Subject: RE: [rohc] sigcomp issue lejo-8
Date: Wed, 17 Apr 2002 13:17:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> Going back to the issue, can we agree on the following?
> 
> a) optimization is not the reason for choosing one over the other.

Hi,

I believe that I now understand Carsten's original objection to the
way the UDVM interfaces with its environment. In Carsten's model the
receiving endpoint buffers a complete SigComp message, invokes the
UDVM to decompress the message, and then closes the UDVM as soon as
the message is decompressed. There is no need for the UDVM to pause
and wait for more data to become available.

However, the current version of the UDVM has a more complex interface
with its environment in order to efficiently support stream-based
transports such as TCP and TLS.

As we discussed on the mailing list a while back, an application may
choose to provide security on the transport layer (e.g. by invoking
SigComp over TLS). In this case there is no need to use the SigComp
state identifiers or message delimiters at all - we don't weaken
application security by avoiding them (because the session IDs are
provided by TLS, independently of the contents of each application
message).

The benefit of omitting the state identifiers and message delimiters
is a compression boost of at least 10 bytes per application message.
The cost is that the UDVM needs to run for the entire duration of a
TLS session - in particular it must have the ability to request new
data from the stream and then pause until the data has arrived.

Another benefit of the pause-and-wait model is that we cut the memory
requirements of the UDVM - there is no need to buffer an entire
SigComp message over a stream-based transport. This is particularly
important for SIP, which uses TCP specifically to carry large messages
that would cause fragmentation to occur over UDP.

> b) the reason we have UDVM is to support different decompression 
> algorithms without negotiation. Nothing more than that. Its minimal
> job is to decompress and interpret state creation requests. Whether 
> one wants to put more functions to UDVM is an implementation issue. 
> Therefore, the text should not dictate either way.
>
> (To me, keeping UDVM lifetime shorter simplifies interfaces. But
> others may want to implement differently.  )

Yes - the difference between the two models is the maximum duration
of the UDVM lifetime. In the buffer-a-whole-message model the UDVM
lifetime is very short, which simplifies the interfaces to the
environment. In the pause-and-wait model the UDVM lifetime is as
long as can be permitted by the application security mechanism - if
TLS is used the UDVM may persist for the entire duration of a TLS
session. This requires a more complex interface to the environment,
but in return it improves the overall compression ratio and reduces
the working memory requirements.

So, which is the better model to adopt? Although we could easily
avoid the pause-and-wait nature of the final state creation request,
I see little benefit in doing so unless we change the pause-and-wait
nature of the INPUT instructions as well. Does anyone see a benefit
in making this change given the advantages and drawbacks outlined
above (plus any others that I've missed)?

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 09:08:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16452
	for ; Wed, 17 Apr 2002 09:08:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07881;
	Wed, 17 Apr 2002 09:06:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07853
	for ; Wed, 17 Apr 2002 09:06:28 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16336
	for ; Wed, 17 Apr 2002 09:06:24 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4NAY>; Wed, 17 Apr 2002 14:00:14 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE4@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Hans Hannu (EPL)'" ,
        "'zhigang.c.liu@nokia.com'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 14:00:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

The S-bit and the I-bit are both items of announcement data; they
carry some information about the capability of the sending endpoint,
which may or may not influence the behaviour of the receiving endpoint.

If the S-bit is set to 1 then the sending endpoint says the following:

"I do not wish to save any new state items at the receiving endpoint,
or to access any state items that I previously created".

The receiving endpoint can do what it likes with this information.
Typically it will set the state_memory_size of the session to 0, and
delete any state items that are no longer needed.

The sending endpoint is welcome to change its mind and switch the S-bit
back to 0 in a later message. However, the receiving endpoint is under
no obligation to use the original state_memory_size for the session; it
may choose to allocate less memory to the session or possibly none at all.

If the I-bit is set to 1 then the sending endpoint says the following:

"I do not wish to access the locally available state items of the
receiving endpoint".

See Section 3.3.3 of the draft for a definition of "locally available
state items". Based on this information the receiving endpoint will
typically stop sending the list of locally available state items (as
the list would only be discarded), but if it chooses to send the list
anyway then the only harm is a slightly reduced compression ratio.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se]
> Sent: Wednesday, April 17, 2002 8:38 AM
> To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue lejo-10
> 
> 
> > Just one editorial comment. Should we add specifications on
> > the receiver behavior as follows?
> > 
> > "If I-bit is set to zero, the receiving endpoint MUST NOT return 
> > the list of locally available state items. Otherwise, it SHOULD
> > return the list. "
> > 
> > Same comment goes to S-bit.
> 
> I do not think it is necessary, SigComp would not crash if it 
> receives this kind of information although it is unwanted. I 
> think the current text should be enough motivation for not 
> sending the list if the I-bit is set.
> 
> Section 9.4.7
> "...This can help to conserve bandwidth by avoiding..."
> 
> BR
> /Hans H
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 10:38:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20768
	for ; Wed, 17 Apr 2002 10:38:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12547;
	Wed, 17 Apr 2002 10:20:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12511
	for ; Wed, 17 Apr 2002 10:20:21 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19424
	for ; Wed, 17 Apr 2002 10:20:16 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4NF4>; Wed, 17 Apr 2002 15:09:21 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE5@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Hans Hannu (EPL)'" ,
        "'rohc@ietf.org'"
	 
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Wed, 17 Apr 2002 15:09:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > decompression_memory_size differs from the proposed resolution,
> > though (maybe I just don't understand 3.3.1; it's certainly not
> > crystal clear).
> 
> My understanding is that decompression_memory_size, includes 
> the former parameters "compressed-message-size" and 
> "UDVM-memory-size" which would correspond to a input buffer 
> and the UDVM byte-buffer (UDVM memory).

Yes, we now announce both the compressed_message_size and the
UDVM_memory_size as a single decompression_memory_size parameter.
This is in line with the proposed resolution that we discussed at
Minneapolis.

> So the only thing this excludes is the former parameter 
> "decompressed-message-size". However, that could also bundle 
> up with the others into the decompression_memory_size, by 
> adding some text to section 3.3.1.

In the proposed SigComp-06 draft the decompressed_message_size is
not announced. The reason for this is as follows:

SigComp can control the amount of memory required by both the
compressed message and by the UDVM, so it can cope with changes
in the available memory by (e.g.) reducing the size of the circular
buffer. Therefore it is useful for the sending endpoint to receive
an announcement of these parameters.

However, SigComp has no control over the amount of memory needed to
buffer decompressed messages (as SigComp can't change the size of the
messages generated by the application). So there is no benefit to
announcing the decompressed_message_size supported by the receiving
endpoint as the sending endpoint can't do anything useful with this
information.

In fact, if the receiving endpoint is particularly memory-starved
then it can output the decompressed message directly into the memory
reserved by the signalling application itself. This avoids the need for
SigComp to provide its own buffer for decompressed messages altogether.

> "The decompression_memory_size parameter specifies the amount of 
>    memory available to decompress one SigComp message. A portion of this 
>    memory is used to buffer a SigComp message before *and after* it
>    is decompressed; the remainder is given to the UDVM..."

The memory used to buffer a decompressed SigComp message is not included
as part of the decompression_memory_size, because the sending endpoint
doesn't care how much memory has been provided for this task. As mentioned
above the memory might even come from the application itself.

> > cycles_per_bit can only be 16 to 128; I believe lower values are
> > required.  (And the default may need to be lower: As it stands, 12000
> > bit messages can use up to 208000 cycles, that is quite a lot,
> > considering that many server-side implementations may need a few
> > hundred ns per cycle, and UE implementations easily can take several
> > us.)
> 
> Hmm, what is a reasonable value for a deflate algorithm, with 
> a compressed message of say 12000 bits?

Since DEFLATE is about the slowest algorithm around, the default value
for cycles_per_bit should be enough to decompress DEFLATE messages (plus
a reasonable margin of safety). DEFLATE needs roughly 1 - 8 cycles per
compressed bit depending on the compression ratio, so a default value of
16 cycles per bit seemed reasonable to me.

Note that a 12000 bit compressed message is rare - it will typically
occur only if the message is poorly compressed (in which case it will
need far less than the maximum available cycles_per_bit).

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 11:11:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22366
	for ; Wed, 17 Apr 2002 11:11:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17817;
	Wed, 17 Apr 2002 10:58:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17772
	for ; Wed, 17 Apr 2002 10:57:56 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21759
	for ; Wed, 17 Apr 2002 10:57:46 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HF0DH11169
	for ; Wed, 17 Apr 2002 10:00:24 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 17 Apr 2002 09:57:33 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 09:57:11 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 09:57:11 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-10
Thread-Index: AcHl4xIQu1i+Xg2fSy61g6hLT2Z68wAOyJ0g
To: , 
X-OriginalArrivalTime: 17 Apr 2002 14:57:11.0476 (UTC) FILETIME=[273D5F40:01C1E620]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17773
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> > Just one editorial comment. Should we add specifications on
> > the receiver behavior as follows?
> > 
> > "If I-bit is set to zero, the receiving endpoint MUST NOT return 
> > the list of locally available state items. Otherwise, it SHOULD
> > return the list. "
> > 
> > Same comment goes to S-bit.
> 
> I do not think it is necessary, SigComp would not crash if it 
> receives this kind of information although it is unwanted. 

No, it doesn't. However, should we not give the sender a
precise control on the receiver's response? Otherwise, what
is the point of I-bit ("hey, here is my request, but feel free
to ignore it)? Or what is the benefit of not specifying above?

(As in any protocol, the consequence of an information element
from a sender to a receiver should be specified clearly unless 
there is a reason to make it fuzzy.)

Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 12:19:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25268
	for ; Wed, 17 Apr 2002 12:19:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19950;
	Wed, 17 Apr 2002 12:06:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19881
	for ; Wed, 17 Apr 2002 12:06:22 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24651
	for ; Wed, 17 Apr 2002 12:06:17 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4N3J>; Wed, 17 Apr 2002 17:01:08 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE7@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        Hans.Hannu@epl.ericsson.se, cabo@Informatik.Uni-Bremen.DE
Cc: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-11
Date: Wed, 17 Apr 2002 17:01:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

The INPUT-FIXED instruction inputs a fixed number of bits, as
opposed to the INPUT-HUFFMAN instruction that inputs a variable
number of bits depending on their value. The terminology for
both instructions is taken from RFC 1951.

I think that INPUT-FIXED is marginally clearer than INPUT-BITS,
because we have two instructions that input bits in a different
manner. Having said that, either term is fine by me ;-)

Regards,

Richard

> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: Wednesday, April 17, 2002 4:28 PM
> To: Hans.Hannu@epl.ericsson.se; cabo@Informatik.Uni-Bremen.DE
> Cc: rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue cabo-11
> 
> 
> > I think INPUT-OCTETS would be clearer.
> 
> Me too. (It seems at least we're able to reach consensus 
> on this name since Richard is fine with either one.)
> 
> Sorry for dragging on this kind of trivial issues, but should 
> we then change the "INPUT-FIXED" to "INPUT-BITS"? Or
> there is a reason to have "FIXED" there?
> 
> Zhigang
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 12:32:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25768
	for ; Wed, 17 Apr 2002 12:32:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26794;
	Wed, 17 Apr 2002 12:26:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26759
	for ; Wed, 17 Apr 2002 12:26:15 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25560
	for ; Wed, 17 Apr 2002 12:26:11 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4NP6>; Wed, 17 Apr 2002 17:22:31 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE8@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 17:22:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> Richard,
> 
> Sorry, I failed to follow your example below. Step 1 and 2 happen 
> before the local endpoint receives the I=1 message. So it is 
> irrelevant to the behavior of a receiver of I=1, which is the 
> subject of discussion here.
> 
> Do you mean that in Step 4, the local endpoint has to keep 
> sending the list of locally available states to avoid reducing
> compression efficiency? Could you clarify further? I'm lost here.

What has happened by Step 4 is that the list of locally available
state is now stored at the remote endpoint as part of the state item
that the local endpoint wishes to access. When the state item is
accessed the list of locally available state will automatically be
copied into the UDVM memory at the returned_parameters_location.

So, how can the local endpoint avoid announcing its list of locally
available state items? It could specifically delete the list from
the UDVM memory, but this would cost additional bits in the
compressed message.

Alternatively it could avoid saving the list as part of the state
item in the first place. However, it's quite costly to precisely
specify which parts of the UDVM memory will be saved as state and
which will be discarded (it would require a lot of COPY instructions
to move all of the data that needs to be saved into a continuous
block). It's much easier to just dump the entire UDVM memory into
state.

Hope this clarifies the example!

Regards,

Richard

> > Here's a (fairly) plausible situation where it is useful to
> > announce a list of locally available state, even though the
> > remote endpoint has indicated that it doesn't need one:
> > 
> > 1.  An endpoint sends its list of locally available state items in
> >     the very first SigComp message of the session.
> > 
> > 2.  The endpoint creates a new state item at the remote endpoint,
> >     which (for simplicity) contains the entire contents of the
> >     UDVM memory including the list of locally available state.
> > 
> > 3.  The remote endpoint returns a message with the I-bit set to 1,
> >     indicating that it doesn't need the locally available state
> >     after all.
> > 
> > 4.  The local endpoint sends a new SigComp message, compressed
> >     relative to the state item it just created.
> > 
> > In this situation it would actually reduce the compression efficiency
> > to stop the list of locally available state from being announced. As
> > it doesn't do any harm to announce the list (even if it will just be
> > thrown away), the local endpoint can choose to keep announcing the
> > list anyway.
> > 
> > However, if the I-bit arrives before the list of locally available
> > state is sent then the compressor won't bother to send it at all.
> > This may save quite a bit of bandwidth if the list is long, which is
> > why I believe the I-bit to be useful.
> > 
> > Regards,
> > 
> > Richard
> > 
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 12:32:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25782
	for ; Wed, 17 Apr 2002 12:32:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26568;
	Wed, 17 Apr 2002 12:23:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26526
	for ; Wed, 17 Apr 2002 12:23:38 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23338
	for ; Wed, 17 Apr 2002 11:34:03 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4NMC>; Wed, 17 Apr 2002 16:30:26 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE6@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 16:30:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > > Just one editorial comment. Should we add specifications on
> > > the receiver behavior as follows?
> > > 
> > > "If I-bit is set to zero, the receiving endpoint MUST NOT return 
> > > the list of locally available state items. Otherwise, it SHOULD
> > > return the list. "
> > > 
> > > Same comment goes to S-bit.
> > 
> > I do not think it is necessary, SigComp would not crash if it 
> > receives this kind of information although it is unwanted. 
> 
> No, it doesn't. However, should we not give the sender a
> precise control on the receiver's response? Otherwise, what
> is the point of I-bit ("hey, here is my request, but feel free
> to ignore it)? Or what is the benefit of not specifying above?
> 
> (As in any protocol, the consequence of an information element
> from a sender to a receiver should be specified clearly unless 
> there is a reason to make it fuzzy.)

Hi,

Here's a (fairly) plausible situation where it is useful to
announce a list of locally available state, even though the
remote endpoint has indicated that it doesn't need one:

1.  An endpoint sends its list of locally available state items in
    the very first SigComp message of the session.

2.  The endpoint creates a new state item at the remote endpoint,
    which (for simplicity) contains the entire contents of the
    UDVM memory including the list of locally available state.

3.  The remote endpoint returns a message with the I-bit set to 1,
    indicating that it doesn't need the locally available state
    after all.

4.  The local endpoint sends a new SigComp message, compressed
    relative to the state item it just created.

In this situation it would actually reduce the compression efficiency
to stop the list of locally available state from being announced. As
it doesn't do any harm to announce the list (even if it will just be
thrown away), the local endpoint can choose to keep announcing the
list anyway.

However, if the I-bit arrives before the list of locally available
state is sent then the compressor won't bother to send it at all.
This may save quite a bit of bandwidth if the list is long, which is
why I believe the I-bit to be useful.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 12:32:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25806
	for ; Wed, 17 Apr 2002 12:32:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27066;
	Wed, 17 Apr 2002 12:28:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27028
	for ; Wed, 17 Apr 2002 12:28:20 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25647
	for ; Wed, 17 Apr 2002 12:28:15 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HGSZs29892
	for ; Wed, 17 Apr 2002 11:28:35 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 17 Apr 2002 11:28:11 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 11:27:50 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 11:27:50 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-10
Thread-Index: AcHmEGxqVjQTp3ScSou1Q/fhaSE/fAAGKzhA
To: , , 
X-OriginalArrivalTime: 17 Apr 2002 16:27:50.0639 (UTC) FILETIME=[D13BC7F0:01C1E62C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA27029
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Thanks for the explanation, Richard. From what you describe
below, S-bit is slightly different from I-bit. Let me know
if following understanding is correct:

- S-bit is basically a "memory release" announcement. We don't
need to specify receiver's behavior (in this regard, what
I said before is wrong).

- However, you described below what the *sender" of S=1
MUST NOT expect if it switches S back to 0. This is not
in current draft. Do we have a synchronization problem here?
I'm concerned about the switch back and forth of S bit.

- I-bit. If I understand correctly, the purpose of I-bit
is to avoid overhead in feedback from remote endpoint.
Then, what is wrong to specify the receiver's behavior
accordingly? (still need to understand your example in the 
other email).

Zhigang

> -----Original Message-----
> From: ext Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: April 17, 2002 8:00 AM
> To: 'Hans Hannu (EPL)'; Liu Zhigang.C (NRC/Dallas); rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue lejo-10
> 
> 
> Hi,
> 
> The S-bit and the I-bit are both items of announcement data; they
> carry some information about the capability of the sending endpoint,
> which may or may not influence the behaviour of the receiving 
> endpoint.
> 
> If the S-bit is set to 1 then the sending endpoint says the following:
> 
> "I do not wish to save any new state items at the receiving endpoint,
> or to access any state items that I previously created".
> 
> The receiving endpoint can do what it likes with this information.
> Typically it will set the state_memory_size of the session to 0, and
> delete any state items that are no longer needed.
> 
> The sending endpoint is welcome to change its mind and switch 
> the S-bit
> back to 0 in a later message. However, the receiving endpoint is under
> no obligation to use the original state_memory_size for the 
> session; it
> may choose to allocate less memory to the session or possibly 
> none at all.
> 
> If the I-bit is set to 1 then the sending endpoint says the following:
> 
> "I do not wish to access the locally available state items of the
> receiving endpoint".
> 
> See Section 3.3.3 of the draft for a definition of "locally available
> state items". Based on this information the receiving endpoint will
> typically stop sending the list of locally available state items (as
> the list would only be discarded), but if it chooses to send the list
> anyway then the only harm is a slightly reduced compression ratio.
> 
> Regards,
> 
> Richard
> 
> > -----Original Message-----
> > From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se]
> > Sent: Wednesday, April 17, 2002 8:38 AM
> > To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org
> > Subject: RE: [rohc] sigcomp issue lejo-10
> > 
> > 
> > > Just one editorial comment. Should we add specifications on
> > > the receiver behavior as follows?
> > > 
> > > "If I-bit is set to zero, the receiving endpoint MUST NOT return 
> > > the list of locally available state items. Otherwise, it SHOULD
> > > return the list. "
> > > 
> > > Same comment goes to S-bit.
> > 
> > I do not think it is necessary, SigComp would not crash if it 
> > receives this kind of information although it is unwanted. I 
> > think the current text should be enough motivation for not 
> > sending the list if the I-bit is set.
> > 
> > Section 9.4.7
> > "...This can help to conserve bandwidth by avoiding..."
> > 
> > BR
> > /Hans H
> > 
> > _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 12:40:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26069
	for ; Wed, 17 Apr 2002 12:40:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27779;
	Wed, 17 Apr 2002 12:32:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27739
	for ; Wed, 17 Apr 2002 12:32:02 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25764
	for ; Wed, 17 Apr 2002 12:31:59 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4NQP>; Wed, 17 Apr 2002 17:28:11 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFE9@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue rp-8
Date: Wed, 17 Apr 2002 17:28:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > On the other hand this instruction fits very well with the 
> > state_retention_priority as parts of the UDVM memory saved as 
> > states can be assigned different deletion priorities, which 
> > may give the compressor more control on the memory management.
> 
> Smaller states give you finer granularity.

Hi,

Another benefit of the STATE-CREATE instruction is that you can save
an important item of state with a high minimum_access_length, at the
same time as saving a less important state item with a low
minimum_access_length.

> > On the third hand after reading the emails regarding sigcomp 
> > issue lejo-8 the STATE-CREATE instruction may imply 
> > additional efforts as the UDVM may hold several pending state 
> > creation requests instead of just a maximum of one.
> 
> We can have say 3 or 4 as the maximum # of state creation requests 
> per message. That gives enough flexibility and yet won't create trouble: 
> you still authenticate the decompressed message only once. 

This is where the STATE-CREATE instruction may cause additional security
concerns. The problem is that if we allow each message to create 4 items
of state rather than just one, a malicious sender who is attempting to
cause a hash collision can fill up the state identifier space 4 times more
quickly. It may be necessary to redo the security considerations to take
this into account.

If it turns out that STATE-CREATE introduces only a negligible additional
security risk then I'd like to see the functionality added to SigComp-06.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 13:07:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27464
	for ; Wed, 17 Apr 2002 13:07:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15529;
	Wed, 17 Apr 2002 12:01:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15434
	for ; Wed, 17 Apr 2002 12:01:19 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24421
	for ; Wed, 17 Apr 2002 12:00:54 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HG3MH19676
	for ; Wed, 17 Apr 2002 11:03:33 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 17 Apr 2002 11:00:42 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 11:00:16 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 11:00:15 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-10
Thread-Index: AcHmJQDaq4haKPzVRNuh7zFhNq2J/wAAmHiQ
To: , , 
X-OriginalArrivalTime: 17 Apr 2002 16:00:16.0990 (UTC) FILETIME=[F794F7E0:01C1E628]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA15437
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Richard,

Sorry, I failed to follow your example below. Step 1 and 2 happen 
before the local endpoint receives the I=1 message. So it is 
irrelevant to the behavior of a receiver of I=1, which is the 
subject of discussion here.

Do you mean that in Step 4, the local endpoint has to keep 
sending the list of locally available states to avoid reducing
compression efficiency? Could you clarify further? I'm lost here.

BR,
Zhigang


> Here's a (fairly) plausible situation where it is useful to
> announce a list of locally available state, even though the
> remote endpoint has indicated that it doesn't need one:
> 
> 1.  An endpoint sends its list of locally available state items in
>     the very first SigComp message of the session.
> 
> 2.  The endpoint creates a new state item at the remote endpoint,
>     which (for simplicity) contains the entire contents of the
>     UDVM memory including the list of locally available state.
> 
> 3.  The remote endpoint returns a message with the I-bit set to 1,
>     indicating that it doesn't need the locally available state
>     after all.
> 
> 4.  The local endpoint sends a new SigComp message, compressed
>     relative to the state item it just created.
> 
> In this situation it would actually reduce the compression efficiency
> to stop the list of locally available state from being announced. As
> it doesn't do any harm to announce the list (even if it will just be
> thrown away), the local endpoint can choose to keep announcing the
> list anyway.
> 
> However, if the I-bit arrives before the list of locally available
> state is sent then the compressor won't bother to send it at all.
> This may save quite a bit of bandwidth if the list is long, which is
> why I believe the I-bit to be useful.
> 
> Regards,
> 
> Richard
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 13:16:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27869
	for ; Wed, 17 Apr 2002 13:16:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27965;
	Wed, 17 Apr 2002 11:29:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27938
	for ; Wed, 17 Apr 2002 11:29:31 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23094
	for ; Wed, 17 Apr 2002 11:29:16 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HFVcH15766
	for ; Wed, 17 Apr 2002 10:31:48 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 17 Apr 2002 10:28:55 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 10:28:00 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue cabo-11
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 17 Apr 2002 10:28:00 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-11
Thread-Index: AcHl4cVnPiDnky48SzCp4FOc7NubhQAQcLPw
To: , 
Cc: 
X-OriginalArrivalTime: 17 Apr 2002 15:28:01.0149 (UTC) FILETIME=[75BB12D0:01C1E624]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA27939
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> I think INPUT-OCTETS would be clearer.

Me too. (It seems at least we're able to reach consensus 
on this name since Richard is fine with either one.)

Sorry for dragging on this kind of trivial issues, but should 
we then change the "INPUT-FIXED" to "INPUT-BITS"? Or
there is a reason to have "FIXED" there?

Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 15:00:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01867
	for ; Wed, 17 Apr 2002 15:00:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08280;
	Wed, 17 Apr 2002 14:55:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08250
	for ; Wed, 17 Apr 2002 14:55:12 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01612
	for ; Wed, 17 Apr 2002 14:55:08 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3HIt9s7015222
	for ; Wed, 17 Apr 2002 20:55:09 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Apr 17 20:55:09 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBT3AK0>; Wed, 17 Apr 2002 20:55:09 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'rohc@ietf.org'" 
Date: Wed, 17 Apr 2002 20:55:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] Closing sigcomp issues - Instalment 1
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Dear SigComp fellows,

We should try to stepwise close the open SigComp issues, starting from
the summary list provided by Carsten:
http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/udvm/
The list has been available for some time, so it should be reasonable
by now to consider the issues to which solutions have been proposed without objections, as closed.

After studying the issues list and the mail discussions, I believe the
following issues should be possible to close:
lejo-1
lejo-2
lejo-3
lejo-4
lejo-5
lejo-6
lejo-11
rp-2
rp-3
rp-4
rp-5
rp-6
rp-7
zliu-1 (covered by cabo-15 and lejo-3)
zliu-2 (covered by lejo-1)
cabo-13
cabo-12
cabo-10
cabo-9
cabo-7
cabo-1 (covered by rp-2)
cabo-2
cabo-14 (covered by rp-7)
cabo-5 (covered by cabo-6)
sugar-1
sugar-2
sugar-4
sugar-5 (covered by cabo-8)
lejo-edit-*

If anyone has objections to closing any of the above issues, according
to the summary list provided by Carsten, please let us know NOW, which and
why it should not yet be closed. 

For the other issues, please let us cooperate to get proposed actions for
all of them. Then we can hopefully close also these. We need to speed up
significantly if we want to get this ready in time for 3GPP.


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. 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 16:13:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05644
	for ; Wed, 17 Apr 2002 16:13:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAB13544;
	Wed, 17 Apr 2002 16:01:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13486
	for ; Wed, 17 Apr 2002 16:01:27 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04995
	for ; Wed, 17 Apr 2002 16:01:19 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HK1cF15751
	for ; Wed, 17 Apr 2002 23:01:38 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 17 Apr 2002 23:01:21 +0300
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 23:01:02 +0300
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 15:00:47 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 15:00:46 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-10
Thread-Index: AcHmLEojSryLjyBESdSdSO5+JVgE0wAGoJUQ
To: , , 
X-OriginalArrivalTime: 17 Apr 2002 20:00:47.0770 (UTC) FILETIME=[90FF3FA0:01C1E64A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA13504
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Richard,

Now that I understand your example, it's clear to me you're
talking about something different. Correct me if I'm wrong,
there is no bytes *transmitted* on the wire (or wireless)
in step 4, right?

However, the issue here is about setting I-bit to 1 "to conserve 
bandwidth by avoiding the transmission of feedback data ...".
I think the confusion is caused by the ambiguity of word "return"
which I used in my proposal. How about the following text?

"If I-bit is set to zero, the receiving endpoint SHOULD stop
transmitting the list of locally available state items to the
sending endpoint. Otherwise, it SHOULD transmit the list. "

(Note that I also changed MUST to SHOULD according to Hans' 
point, i.e., it will not cause a failure of the sender if the 
receiver does not follow above text.)

Zhigang

> -----Original Message-----
> From: ext Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: April 17, 2002 11:22 AM
> To: Liu Zhigang.C (NRC/Dallas); Hans.Hannu@epl.ericsson.se;
> rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue lejo-10
> 
> 
> > Richard,
> > 
> > Sorry, I failed to follow your example below. Step 1 and 2 happen 
> > before the local endpoint receives the I=1 message. So it is 
> > irrelevant to the behavior of a receiver of I=1, which is the 
> > subject of discussion here.
> > 
> > Do you mean that in Step 4, the local endpoint has to keep 
> > sending the list of locally available states to avoid reducing
> > compression efficiency? Could you clarify further? I'm lost here.
> 
> What has happened by Step 4 is that the list of locally available
> state is now stored at the remote endpoint as part of the state item
> that the local endpoint wishes to access. When the state item is
> accessed the list of locally available state will automatically be
> copied into the UDVM memory at the returned_parameters_location.
> 
> So, how can the local endpoint avoid announcing its list of locally
> available state items? It could specifically delete the list from
> the UDVM memory, but this would cost additional bits in the
> compressed message.
> 
> Alternatively it could avoid saving the list as part of the state
> item in the first place. However, it's quite costly to precisely
> specify which parts of the UDVM memory will be saved as state and
> which will be discarded (it would require a lot of COPY instructions
> to move all of the data that needs to be saved into a continuous
> block). It's much easier to just dump the entire UDVM memory into
> state.
> 
> Hope this clarifies the example!
> 
> Regards,
> 
> Richard
> 
> > > Here's a (fairly) plausible situation where it is useful to
> > > announce a list of locally available state, even though the
> > > remote endpoint has indicated that it doesn't need one:
> > > 
> > > 1.  An endpoint sends its list of locally available state items in
> > >     the very first SigComp message of the session.
> > > 
> > > 2.  The endpoint creates a new state item at the remote endpoint,
> > >     which (for simplicity) contains the entire contents of the
> > >     UDVM memory including the list of locally available state.
> > > 
> > > 3.  The remote endpoint returns a message with the I-bit set to 1,
> > >     indicating that it doesn't need the locally available state
> > >     after all.
> > > 
> > > 4.  The local endpoint sends a new SigComp message, compressed
> > >     relative to the state item it just created.
> > > 
> > > In this situation it would actually reduce the 
> compression efficiency
> > > to stop the list of locally available state from being 
> announced. As
> > > it doesn't do any harm to announce the list (even if it 
> will just be
> > > thrown away), the local endpoint can choose to keep announcing the
> > > list anyway.
> > > 
> > > However, if the I-bit arrives before the list of locally available
> > > state is sent then the compressor won't bother to send it at all.
> > > This may save quite a bit of bandwidth if the list is 
> long, which is
> > > why I believe the I-bit to be useful.
> > > 
> > > Regards,
> > > 
> > > Richard
> > > 
> > 
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 16:36:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06564
	for ; Wed, 17 Apr 2002 16:36:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14735;
	Wed, 17 Apr 2002 16:25:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14703
	for ; Wed, 17 Apr 2002 16:24:59 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06120
	for ; Wed, 17 Apr 2002 16:24:55 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HKO3u02569
	for ; Wed, 17 Apr 2002 23:24:03 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 17 Apr 2002 23:24:56 +0300
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 23:24:56 +0300
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 15:24:30 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Wed, 17 Apr 2002 15:24:29 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-10
Thread-Index: AcHmLEojSryLjyBESdSdSO5+JVgE0wAGoJUQAAGj7RA=
To: , , 
X-OriginalArrivalTime: 17 Apr 2002 20:24:30.0201 (UTC) FILETIME=[E0D4FE90:01C1E64D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA14705
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Sorry, a typo in my text (zero should be 1), it should read:

"If I-bit is set to 1, the receiving endpoint SHOULD stop
transmitting the list of locally available state items to the
sending endpoint. Otherwise, it SHOULD transmit the list."

Zhigang

> -----Original Message-----
> From: Liu Zhigang.C (NRC/Dallas) 
> Sent: April 17, 2002 3:01 PM
> To: richard.price@roke.co.uk; Hans.Hannu@epl.ericsson.se; 
> rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue lejo-10
> 
> 
> Richard,
> 
> Now that I understand your example, it's clear to me you're
> talking about something different. Correct me if I'm wrong,
> there is no bytes *transmitted* on the wire (or wireless)
> in step 4, right?
> 
> However, the issue here is about setting I-bit to 1 "to conserve 
> bandwidth by avoiding the transmission of feedback data ...".
> I think the confusion is caused by the ambiguity of word "return"
> which I used in my proposal. How about the following text?
> 
> "If I-bit is set to zero, the receiving endpoint SHOULD stop
> transmitting the list of locally available state items to the
> sending endpoint. Otherwise, it SHOULD transmit the list. "
> 
> (Note that I also changed MUST to SHOULD according to Hans' 
> point, i.e., it will not cause a failure of the sender if the 
> receiver does not follow above text.)
> 
> Zhigang
> 
> > -----Original Message-----
> > From: ext Price, Richard [mailto:richard.price@roke.co.uk]
> > Sent: April 17, 2002 11:22 AM
> > To: Liu Zhigang.C (NRC/Dallas); Hans.Hannu@epl.ericsson.se;
> > rohc@ietf.org
> > Subject: RE: [rohc] sigcomp issue lejo-10
> > 
> > 
> > > Richard,
> > > 
> > > Sorry, I failed to follow your example below. Step 1 and 2 happen 
> > > before the local endpoint receives the I=1 message. So it is 
> > > irrelevant to the behavior of a receiver of I=1, which is the 
> > > subject of discussion here.
> > > 
> > > Do you mean that in Step 4, the local endpoint has to keep 
> > > sending the list of locally available states to avoid reducing
> > > compression efficiency? Could you clarify further? I'm lost here.
> > 
> > What has happened by Step 4 is that the list of locally available
> > state is now stored at the remote endpoint as part of the state item
> > that the local endpoint wishes to access. When the state item is
> > accessed the list of locally available state will automatically be
> > copied into the UDVM memory at the returned_parameters_location.
> > 
> > So, how can the local endpoint avoid announcing its list of locally
> > available state items? It could specifically delete the list from
> > the UDVM memory, but this would cost additional bits in the
> > compressed message.
> > 
> > Alternatively it could avoid saving the list as part of the state
> > item in the first place. However, it's quite costly to precisely
> > specify which parts of the UDVM memory will be saved as state and
> > which will be discarded (it would require a lot of COPY instructions
> > to move all of the data that needs to be saved into a continuous
> > block). It's much easier to just dump the entire UDVM memory into
> > state.
> > 
> > Hope this clarifies the example!
> > 
> > Regards,
> > 
> > Richard
> > 
> > > > Here's a (fairly) plausible situation where it is useful to
> > > > announce a list of locally available state, even though the
> > > > remote endpoint has indicated that it doesn't need one:
> > > > 
> > > > 1.  An endpoint sends its list of locally available 
> state items in
> > > >     the very first SigComp message of the session.
> > > > 
> > > > 2.  The endpoint creates a new state item at the remote 
> endpoint,
> > > >     which (for simplicity) contains the entire contents of the
> > > >     UDVM memory including the list of locally available state.
> > > > 
> > > > 3.  The remote endpoint returns a message with the 
> I-bit set to 1,
> > > >     indicating that it doesn't need the locally available state
> > > >     after all.
> > > > 
> > > > 4.  The local endpoint sends a new SigComp message, compressed
> > > >     relative to the state item it just created.
> > > > 
> > > > In this situation it would actually reduce the 
> > compression efficiency
> > > > to stop the list of locally available state from being 
> > announced. As
> > > > it doesn't do any harm to announce the list (even if it 
> > will just be
> > > > thrown away), the local endpoint can choose to keep 
> announcing the
> > > > list anyway.
> > > > 
> > > > However, if the I-bit arrives before the list of 
> locally available
> > > > state is sent then the compressor won't bother to send 
> it at all.
> > > > This may save quite a bit of bandwidth if the list is 
> > long, which is
> > > > why I believe the I-bit to be useful.
> > > > 
> > > > Regards,
> > > > 
> > > > Richard
> > > > 
> > > 
> > 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 17:25:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08438
	for ; Wed, 17 Apr 2002 17:25:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19271;
	Wed, 17 Apr 2002 17:22:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19229
	for ; Wed, 17 Apr 2002 17:21:58 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08371
	for ; Wed, 17 Apr 2002 17:21:53 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3HLMCF07480
	for ; Thu, 18 Apr 2002 00:22:13 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 18 Apr 2002 00:21:55 +0300
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 00:21:55 +0300
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 17 Apr 2002 16:21:52 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] Closing sigcomp issues - Instalment 1
Date: Wed, 17 Apr 2002 16:21:51 -0500
Message-ID: 
Thread-Topic: [rohc] Closing sigcomp issues - Instalment 1
Thread-Index: AcHmQYcMoJOVx3EOT+++e90iJMJcxwAEwQOw
To: , 
X-OriginalArrivalTime: 17 Apr 2002 21:21:52.0474 (UTC) FILETIME=[E4962BA0:01C1E655]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA19230
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

It's good to summarize now so we can move ahead and focus on 
issues still open.

One comment, I don't think zliu-1 (see below) is ready to
close since cabo-15 is not closed.

"zliu-1: (this is related to cabo-15) what are the default
minimal values..."

Also, I just found out a typo in Carsten's list. It should
read zliu-1 in the line: "(zliu-2: this is related to cabo-15)". 
That confused me for a while when I was trying to sort things out.

Zhigang

> -----Original Message-----
> From: ext Lars-Erik Jonsson (EPL)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: April 17, 2002 1:56 PM
> To: 'rohc@ietf.org'
> Subject: [rohc] Closing sigcomp issues - Instalment 1
> 
> 
> Dear SigComp fellows,
> 
> We should try to stepwise close the open SigComp issues, starting from
> the summary list provided by Carsten:
> http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/udvm/
> The list has been available for some time, so it should be reasonable
> by now to consider the issues to which solutions have been 
> proposed without objections, as closed.
> 
> After studying the issues list and the mail discussions, I believe the
> following issues should be possible to close:
> lejo-1
> lejo-2
> lejo-3
> lejo-4
> lejo-5
> lejo-6
> lejo-11
> rp-2
> rp-3
> rp-4
> rp-5
> rp-6
> rp-7
> zliu-1 (covered by cabo-15 and lejo-3)
> zliu-2 (covered by lejo-1)
> cabo-13
> cabo-12
> cabo-10
> cabo-9
> cabo-7
> cabo-1 (covered by rp-2)
> cabo-2
> cabo-14 (covered by rp-7)
> cabo-5 (covered by cabo-6)
> sugar-1
> sugar-2
> sugar-4
> sugar-5 (covered by cabo-8)
> lejo-edit-*
> 
> If anyone has objections to closing any of the above issues, according
> to the summary list provided by Carsten, please let us know 
> NOW, which and
> why it should not yet be closed. 
> 
> For the other issues, please let us cooperate to get proposed 
> actions for
> all of them. Then we can hopefully close also these. We need 
> to speed up
> significantly if we want to get this ready in time for 3GPP.
> 
> 
> 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. 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 17:43:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08811
	for ; Wed, 17 Apr 2002 17:43:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20815;
	Wed, 17 Apr 2002 17:42:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20784
	for ; Wed, 17 Apr 2002 17:42:32 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08768
	for ; Wed, 17 Apr 2002 17:42:28 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3HLgIu27477;
	Wed, 17 Apr 2002 23:42:21 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Price, Richard" 
Cc: "'zhigang.c.liu@nokia.com'" ,
        Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: Re: [rohc] sigcomp issue cabo-11
References: <76C92FBBFB58D411AE760090271ED41804A0EFE7@rsys002a.roke.co.uk>
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 17 Apr 2002 23:42:15 +0200
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0EFE7@rsys002a.roke.co.uk>
Message-ID: 
Lines: 19
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

"Price, Richard"  writes:

> Hi,
> 
> The INPUT-FIXED instruction inputs a fixed number of bits, as
> opposed to the INPUT-HUFFMAN instruction that inputs a variable
> number of bits depending on their value. The terminology for
> both instructions is taken from RFC 1951.
> 
> I think that INPUT-FIXED is marginally clearer than INPUT-BITS,
> because we have two instructions that input bits in a different
> manner. Having said that, either term is fine by me ;-)

Since I, too, slightly prefer INPUT-BITS (and I need to be compensated
as I hate INPUT-OCTETS :-), I have made the two editorial changes.

Now on to the real cabo-11...

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 17:55:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09076
	for ; Wed, 17 Apr 2002 17:55:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21315;
	Wed, 17 Apr 2002 17:53:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21284
	for ; Wed, 17 Apr 2002 17:53:48 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09035
	for ; Wed, 17 Apr 2002 17:53:43 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3HLrbu05532;
	Wed, 17 Apr 2002 23:53:41 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Price, Richard" 
Cc: zhigang.c.liu@nokia.com, Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: Re: [rohc] sigcomp issue cabo-11
References: <76C92FBBFB58D411AE760090271ED41804A0EFE2@rsys002a.roke.co.uk>
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 17 Apr 2002 23:53:33 +0200
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0EFE2@rsys002a.roke.co.uk>
Message-ID: 
Lines: 21
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Richard,

I continue to believe the "instantaneous UDVM" model has significant
advantages.  In particular, a multi-session/compartment implementation
needs only one UDVM core, which therefore can be much larger than the
per-compartment/session buffer size.

On the other hand, the "persistent UDVM" model does have its merits,
as you say.  So I'm wondering: Can we accommodate both implementation
strategies?

I.e., can we accept an implementation that always assembles a full
message before starting the UDVM?  This would mean that a compressor
implementation cannot rely on output being generated before the end of
the input message is reached.  I'm not sure that fits your interesting
model of TLS usage.  We could bridge the gap by providing a "push"
delimiter in the record marking scheme; this would make it clear that
the compressor relies on the "persistent UDVM" model and that the UDVM
needs to be started with the data up to the push.

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 17 18:29:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09650
	for ; Wed, 17 Apr 2002 18:29:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22463;
	Wed, 17 Apr 2002 18:16:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22434
	for ; Wed, 17 Apr 2002 18:16:02 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09385
	for ; Wed, 17 Apr 2002 18:15:57 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3HMFqu09469;
	Thu, 18 Apr 2002 00:15:56 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: zhigang.c.liu@nokia.com
Cc: , 
Subject: Re: [rohc] Closing sigcomp issues - Instalment 1
References: 
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 18 Apr 2002 00:15:50 +0200
In-Reply-To: 
Message-ID: 
Lines: 26
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

zhigang.c.liu@nokia.com writes:

> One comment, I don't think zliu-1 (see below) is ready to
> close since cabo-15 is not closed.

I believe Lars-Erik was trying to cut down the number of references to
each open issue to one.  Since zliu-1 is covered by the current text
of cabo-15, we don't need it separately on the list to be discussed.
Same as for sugar-5 (cabo-8 is still open) etc.

> Also, I just found out a typo in Carsten's list. It should
> read zliu-1 in the line: "(zliu-2: this is related to cabo-15)". 
> That confused me for a while when I was trying to sort things out.

Fixed.

I agree with Lars-Erik's list, with one possible exception:

> > cabo-10

I think we have technical consensus here, but before we close this
issue, could please at least one additional implementer nod on the
list?  I'd like to make sure people understand the current text and
believe it is unambiguous.

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 04:27:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28851
	for ; Thu, 18 Apr 2002 04:27:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06192;
	Thu, 18 Apr 2002 04:21:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06161
	for ; Thu, 18 Apr 2002 04:21:57 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28755
	for ; Thu, 18 Apr 2002 04:21:51 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3I8Lfs7026391
	for ; Thu, 18 Apr 2002 10:21:41 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 18 10:21:02 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 18 Apr 2002 10:10:33 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'cabo@Informatik.Uni-Bremen.DE'" ,
        zhigang.c.liu@nokia.com
Cc: "Lars-Erik Jonsson (EPL)" ,
        rohc@ietf.org
Subject: RE: [rohc] Closing sigcomp issues - Instalment 1
Date: Thu, 18 Apr 2002 10:20:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> > One comment, I don't think zliu-1 (see below) is ready to
> > close since cabo-15 is not closed.
> 
> I believe Lars-Erik was trying to cut down the number of references to
> each open issue to one.  Since zliu-1 is covered by the current text
> of cabo-15, we don't need it separately on the list to be discussed.
> Same as for sugar-5 (cabo-8 is still open) etc.

Right, that was the idea. If we can get some more opinions on the fix
for cabo-10, and if there are no other objections, we could close these
issues and go further with the rest.

/L-E 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 08:10:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02248
	for ; Thu, 18 Apr 2002 08:10:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20395;
	Thu, 18 Apr 2002 08:02:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20359
	for ; Thu, 18 Apr 2002 08:02:32 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02099
	for ; Thu, 18 Apr 2002 08:02:24 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R43TA>; Thu, 18 Apr 2002 12:53:41 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFEB@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Thu, 18 Apr 2002 12:53:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> Now that I understand your example, it's clear to me you're
> talking about something different. Correct me if I'm wrong,
> there is no bytes *transmitted* on the wire (or wireless)
> in step 4, right?

Right.

> However, the issue here is about setting I-bit to 1 "to conserve 
> bandwidth by avoiding the transmission of feedback data ...".
> I think the confusion is caused by the ambiguity of word "return"
> which I used in my proposal.

Yes, the weasel word "return" caused the confusion on this issue.
Thanks to the presence of state information we have to distinguish
between the data transmitted from the compressor to the UDVM, and
the data forwarded from the UDVM to the state handler (which may
either be uploaded or accessed from a state item).

Since we wish to avoid the *transmission* of unnecessary feedback
data, we need to make a recommendation on the behaviour of the
compressor (Chapter 5 in the base SigComp draft).

In fact we already have the following text on the subject:

"The compressor SHOULD also upload the local SigComp parameters
to the remote endpoint, unless the endpoint has indicated that
it does not wish to receive these parameters or the compressor
determines that the parameters have already successfully arrived."

> How about the following text?
> 
> "If I-bit is set to 1, the receiving endpoint SHOULD stop
> transmitting the list of locally available state items to the
> sending endpoint. Otherwise, it SHOULD transmit the list."

This text is along the lines of the text we currently have, but in
more detail as it refers specifically to the I-bit. We should
certainly add some more detail if the current text is confusing.
However we should also make sure to mention the S-bit as well,
since this behaves in a similar manner to the I-bit (the compressor
sends the state_memory_size unless the S-bit is set to 1, in which
case it doesn't send the state_memory_size to save bandwidth).

> (Note that I also changed MUST to SHOULD according to Hans' 
> point, i.e., it will not cause a failure of the sender if the 
> receiver does not follow above text.)

The text we currently have on this issue also uses a SHOULD for
the same reason.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 08:36:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03013
	for ; Thu, 18 Apr 2002 08:36:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21437;
	Thu, 18 Apr 2002 08:25:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21412
	for ; Thu, 18 Apr 2002 08:25:11 -0400 (EDT)
Received: from h3gshmsw1.hutchison3g.com ([63.137.144.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02717
	for ; Thu, 18 Apr 2002 08:25:07 -0400 (EDT)
Received: from andromeda.h3guk.com (unverified) by h3gshmsw1.hutchison3g.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Thu, 18 Apr 2002 13:26:25 +0100
Received: by andromeda.h3guk.com with Internet Mail Service (5.5.2653.19)
	id <2WWPF0J8>; Thu, 18 Apr 2002 13:26:00 +0100
Message-ID: 
From: Kevan Hobbis 
To: rohc@ietf.org
Date: Thu, 18 Apr 2002 13:26:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [rohc] RFC 2508 Performance Questions
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


Colleagues

I realise you are all busy with more forward looking things, but I have a
couple of questions on the performance of RFC2508 compression.

I would like to find out what is the performance i.e. specifically the
following questions

i) how often is a full header sent ?
ii) how quickly does the compression become optimised to the 4/2 byte header
?
iii) how often is feedback required on return path ?

I hope that working implementations and/or simulations will mean that
someone on the list has some numbers for these. I would greatly appreciate
any information you can make available.

Thanks

Kevan Hobbis
Hutchison 3G UK


________________________________________________________________________

This e-mail message (including any attachment) is intended only for the personal 
use of the recipient(s) named above. This message is confidential and may be 
legally privileged.  If you are not an intended recipient, you may not review, copy or 
distribute this message. If you have received this communication in error, please notify 
us immediately by e-mail and delete the original message.

Any views or opinions expressed in this message are those of the author only. 
Furthermore, this message (including any attachment) does not create any legally 
binding rights or obligations whatsoever, which may only be created by the exchange 
of hard copy documents signed by a duly authorised representative of Hutchison 
3G UK Limited.
________________________________________________________________________


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 08:39:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03125
	for ; Thu, 18 Apr 2002 08:39:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22175;
	Thu, 18 Apr 2002 08:33:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22138
	for ; Thu, 18 Apr 2002 08:33:00 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02928
	for ; Thu, 18 Apr 2002 08:32:56 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3ICWr325724;
	Thu, 18 Apr 2002 14:32:56 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: 
Subject: cabo-10 (Re: [rohc] Closing sigcomp issues - Instalment 1)
References: 
	
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 18 Apr 2002 14:32:52 +0200
In-Reply-To: 
Message-ID: 
Lines: 18
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann) writes:

> > > cabo-10
> 
> I think we have technical consensus here, but before we close this
> issue, could please at least one additional implementer nod on the
> list?  I'd like to make sure people understand the current text and
> believe it is unambiguous.

I just re-read 8.2 and applied some editorial clarifications.
I believe it's now almost painfully clear, but that's what authors
always believe...
Implementers: You may want to check the CVS site again before nodding.

(The name F-bit is slightly unmotivated, now that the instruction is
called INPUT-BITS.  I didn't change the name of the bit.)

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 14:03:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17437
	for ; Thu, 18 Apr 2002 14:03:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20410;
	Thu, 18 Apr 2002 13:58:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20379
	for ; Thu, 18 Apr 2002 13:58:38 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17260
	for ; Thu, 18 Apr 2002 13:58:34 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3IHwrF13947
	for ; Thu, 18 Apr 2002 20:58:54 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 18 Apr 2002 20:58:35 +0300
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 20:58:35 +0300
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 12:58:33 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Thu, 18 Apr 2002 12:58:33 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue lejo-10
Thread-Index: AcHmz+WT0LY50tuwR0ycVLBDhnbTYgAKz2Lg
To: , , 
X-OriginalArrivalTime: 18 Apr 2002 17:58:33.0566 (UTC) FILETIME=[A7E247E0:01C1E702]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA20380
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> > How about the following text?
> > 
> > "If I-bit is set to 1, the receiving endpoint SHOULD stop
> > transmitting the list of locally available state items to the
> > sending endpoint. Otherwise, it SHOULD transmit the list."
> 
> This text is along the lines of the text we currently have, but in
> more detail as it refers specifically to the I-bit. We should
> certainly add some more detail if the current text is confusing.

To make implementers' life easier, I suggest to make the text in 9.4.7 
(redundantly) clear. The current text uses "returned" which is confusing 
just as we saw. Also, we can add explicit reference to I-bit in section 5.

> However we should also make sure to mention the S-bit as well,
> since this behaves in a similar manner to the I-bit (the compressor
> sends the state_memory_size unless the S-bit is set to 1, in which
> case it doesn't send the state_memory_size to save bandwidth).

It's not entirely clear to me about the function of S-bit. But I'll
discuss that in cabo-15 (zliu-1). Here, a question about transmission
of state_memory_size: is it transmitted as part of "returned feedback
item" in Figure 3 or as part of "remaining SigComp message"? I guess
the answer is the latter. Then that means you can upload the value
of state_memory_size in your custom format. If this is correct, we
should:

1) add text to clarify this in 9.4.7, i.e. The format of Figure 13 is 
only for *local* presentation of parameters on the interface between 
UDVM and state handler, NOT a format for transmission between two 
endpoints.

2) add text in section 3.3.1 indicating the encoding format is only
for Figure 13.

This leads to my next question: what is the purpose of "returned feedback
item" then? Specifically, I'm confused by the following text in 7.1.
How does a state handler make use of it? Probably there is something
not spelled out in the draft.

"The returned feedback item is not copied to the UDVM memory; instead
it is buffered until the UDVM has successfully decompressed the
SigComp message. It is then forwarded to the state handler with the
rest of the feedback data (see Section 9.4.7 for further details)."

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 17:11:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23096
	for ; Thu, 18 Apr 2002 17:11:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03015;
	Thu, 18 Apr 2002 17:03:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02887
	for ; Thu, 18 Apr 2002 17:03:42 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22855
	for ; Thu, 18 Apr 2002 17:03:36 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3IL3tF05795
	for ; Fri, 19 Apr 2002 00:03:55 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 19 Apr 2002 00:03:36 +0300
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 19 Apr 2002 00:03:36 +0300
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 16:03:03 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Thu, 18 Apr 2002 16:03:02 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-15
Thread-Index: AcHmH231OZjWa+pbSXu6aqqD/2CYeAA8xiRw
To: , , 
X-OriginalArrivalTime: 18 Apr 2002 21:03:03.0278 (UTC) FILETIME=[6DF248E0:01C1E71C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA02893
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

Following is my understanding of the default minimum values 
of SigComp parameters according to section 3.3. Please shout
if they are incorrect.

decompression_memory_size: 2048 octets
state_memory_size: 0 octets
cycles_per_bit: 16
SigComp_version: 0
locally available state: none

Question: why do we set state_memory_size to 0? Why not
2048, which is not too large even for a low end terminal
but still large enough to be meaningfully used?

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 18:38:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24786
	for ; Thu, 18 Apr 2002 18:38:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09376;
	Thu, 18 Apr 2002 18:33:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09344
	for ; Thu, 18 Apr 2002 18:33:13 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24696
	for ; Thu, 18 Apr 2002 18:33:07 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3IMX2301793;
	Fri, 19 Apr 2002 00:33:05 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: zhigang.c.liu@nokia.com
Cc: , , 
Subject: Re: [rohc] sigcomp issue cabo-15
References: 
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 19 Apr 2002 00:33:01 +0200
In-Reply-To: 
Message-ID: 
Lines: 36
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

zhigang.c.liu@nokia.com writes:

> Question: why do we set state_memory_size to 0? Why not
> 2048, which is not too large even for a low end terminal
> but still large enough to be meaningfully used?

Arguments for setting it to 0:

-- Remember that state_memory_size is per compartment/session.
   There may be many implementations that don't have a known upper
   bound on the number of sessions/compartments they have to support.
   If these are also memory-starved, they are better off with a
   default of 0 -- whenever memory permits, they can always announce a
   larger value (after allocating some space out of their limited pool
   to the specific compartment/session).

-- Some implementations may simply not want to implement state at all.
   With a default of 2048, they would have to accept at least as much.
   (Of course, this smacks like an "option", so I'm not sure I want to
   follow this reasoning too much -- on the other hand, a host may
   simply not *have* any stable storage that would survive long enough.)

Arguments for setting it to a small number like 2048:

-- The first message in an exchange can already download state; this
   allows to improve compression significantly after the first
   roundtrip.  (Otherwise, the improvement only comes after the second
   roundtrip.)  This is essentially the "avoid negotiation" argument.

A "default" different from zero could be an application specific
"default" -- so, even if the general-Internet sigcomp sets the
"default default" to zero, 3GPP could always mandate a different
default, or derive the actual state_memory_size value from any 3GPP
specific discovery process.

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 20:03:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25998
	for ; Thu, 18 Apr 2002 20:03:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13749;
	Thu, 18 Apr 2002 20:01:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13716
	for ; Thu, 18 Apr 2002 20:01:56 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25973
	for ; Thu, 18 Apr 2002 20:01:46 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3J04TH18591
	for ; Thu, 18 Apr 2002 19:04:29 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 18 Apr 2002 19:01:48 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 19:01:23 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Thu, 18 Apr 2002 19:01:22 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-15
Thread-Index: AcHnKQWJpBKALjpZS5eojMA/gyMoGAABHv/w
To: 
Cc: , , 
X-OriginalArrivalTime: 19 Apr 2002 00:01:23.0423 (UTC) FILETIME=[57BAD6F0:01C1E735]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA13717
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

[Carsten wrote:]

> Arguments for setting it to 0:
> 
> -- Remember that state_memory_size is per compartment/session.
>    There may be many implementations that don't have a known upper
>    bound on the number of sessions/compartments they have to support....

Yes, a good argument for a server talking to millions clients.
 
>  -- on the other hand, a host may simply not *have* any stable 
> storage that would survive long enough.)

I'm lack of imagination here. In practice, what kind of host that
would be?
 
> Arguments for setting it to a small number like 2048:
> 
> -- The first message in an exchange can already download state; this
>    allows to improve compression significantly after the first
>    roundtrip.  (Otherwise, the improvement only comes after the second
>    roundtrip.)  This is essentially the "avoid negotiation" argument.

Yes, I remember this is how we started.

> A "default" different from zero could be an application specific
> "default" -- so, even if the general-Internet sigcomp sets the
> "default default" to zero, 3GPP could always mandate a different
> default, or derive the actual state_memory_size value from any 3GPP
> specific discovery process.

This makes me think if we need negotiation after all. Otherwise, we may 
have 3GPP default, non-3GPP default, and what happens if 3GPP host 
talks to non-3GPP hosts, etc.? On the other hand, since we don't even 
have a solution for SigComp discovery in general, this might be the
only (practical) way out.

Zhigang


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 18 20:21:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26326
	for ; Thu, 18 Apr 2002 20:21:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14450;
	Thu, 18 Apr 2002 20:19:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14419
	for ; Thu, 18 Apr 2002 20:19:15 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26305
	for ; Thu, 18 Apr 2002 20:19:07 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3J0LoH19469
	for ; Thu, 18 Apr 2002 19:21:50 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 18 Apr 2002 19:19:09 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 19:18:32 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Thu, 18 Apr 2002 19:18:31 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-15
Thread-Index: AcHmH231OZjWa+pbSXu6aqqD/2CYeABBX/jA
To: , , 
X-OriginalArrivalTime: 19 Apr 2002 00:18:32.0436 (UTC) FILETIME=[BD11C340:01C1E737]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA14420
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> Yes, we now announce both the compressed_message_size and the
> UDVM_memory_size as a single decompression_memory_size parameter.
> This is in line with the proposed resolution that we discussed at
> Minneapolis.

Yes, that helps the goal of reducing the number of parameters.
However, that makes implementation tricky on the receiver end. 
It has to expect any combination of compressed_message_size 
and UDVM_memory_size that totals to 2048 octets. The situation
is worsen by the fact that the former is for decompressor dispatcher 
and the latter is for UDVM. How can one avoid having two buffer
with 2048 octets each?

Also, two related questions:
- What will be the "special value" for UDVM_memory_size in Figure 5?
- What does decompression_memory_size mean exactly for "stream-
compression" case?

Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Fri Apr 19 06:09:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14976
	for ; Fri, 19 Apr 2002 06:09:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28671;
	Fri, 19 Apr 2002 06:01:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28622
	for ; Fri, 19 Apr 2002 06:01:53 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14852
	for ; Fri, 19 Apr 2002 06:01:46 -0400 (EDT)
Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2VH2V4Z6>; Fri, 19 Apr 2002 10:58:50 +0100
Received: from roke.co.uk (percy.roke.co.uk [193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2V2R4QDB; Fri, 19 Apr 2002 10:58:49 +0100
From: "West, Mark (ITN)" 
To: "Dr. Carsten Bormann" 
Cc: rohc@ietf.org
Message-ID: <3CBFEA53.7050208@roke.co.uk>
Date: Fri, 19 Apr 2002 10:58:43 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
Subject: Re: cabo-10 (Re: [rohc] Closing sigcomp issues - Instalment 1)
References: 	 
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Hi all,

>>>>cabo-10
>>>>
>>I think we have technical consensus here, but before we close this
>>issue, could please at least one additional implementer nod on the
>>list?  I'd like to make sure people understand the current text and
>>believe it is unambiguous.

>>





> 
> I just re-read 8.2 and applied some editorial clarifications.
> I believe it's now almost painfully clear, but that's what authors
> always believe...
> Implementers: You may want to check the CVS site again before nodding.
> 


It looks pretty clear from where I'm sitting!  (Of course, I don't know 
that my understanding is the same as everyone elses, but... ;-)

> (The name F-bit is slightly unmotivated, now that the instruction is
> called INPUT-BITS.  I didn't change the name of the bit.)


True - but it is clear what it refers to.  So that's ok, I guess.

Cheers,

Mark.


-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Fri Apr 19 07:06:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15694
	for ; Fri, 19 Apr 2002 07:06:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01394;
	Fri, 19 Apr 2002 06:58:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01362
	for ; Fri, 19 Apr 2002 06:58:24 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15581
	for ; Fri, 19 Apr 2002 06:58:22 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3JAwN3G025694
	for ; Fri, 19 Apr 2002 12:58:23 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 19 12:57:31 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 19 Apr 2002 12:47:01 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'rohc@ietf.org'" 
Date: Fri, 19 Apr 2002 12:56:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] Closed: Closing sigcomp issues - Instalment 1
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Since we now seem to be satisfied with the solution for cabo-10, and
and since we have not heard any other objections to Instalment 1,
we can now consider these issues as closed.

BR
/Lars-Erik



> -----Original Message-----
> From: Lars-Erik Jonsson (EPL) 
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: den 17 april 2002 20:56
> To: 'rohc@ietf.org'
> Subject: [rohc] Closing sigcomp issues - Instalment 1
> 
> 
> Dear SigComp fellows,
> 
> We should try to stepwise close the open SigComp issues, starting from
> the summary list provided by Carsten:
> http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/udvm/
> The list has been available for some time, so it should be reasonable
> by now to consider the issues to which solutions have been 
> proposed without objections, as closed.
> 
> After studying the issues list and the mail discussions, I believe the
> following issues should be possible to close:
> lejo-1
> lejo-2
> lejo-3
> lejo-4
> lejo-5
> lejo-6
> lejo-11
> rp-2
> rp-3
> rp-4
> rp-5
> rp-6
> rp-7
> zliu-1 (covered by cabo-15 and lejo-3)
> zliu-2 (covered by lejo-1)
> cabo-13
> cabo-12
> cabo-10
> cabo-9
> cabo-7
> cabo-1 (covered by rp-2)
> cabo-2
> cabo-14 (covered by rp-7)
> cabo-5 (covered by cabo-6)
> sugar-1
> sugar-2
> sugar-4
> sugar-5 (covered by cabo-8)
> lejo-edit-*
> 
> If anyone has objections to closing any of the above issues, according
> to the summary list provided by Carsten, please let us know 
> NOW, which and
> why it should not yet be closed. 
> 
> For the other issues, please let us cooperate to get proposed 
> actions for
> all of them. Then we can hopefully close also these. We need 
> to speed up
> significantly if we want to get this ready in time for 3GPP.
> 
> 
> 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. 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Fri Apr 19 11:47:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24494
	for ; Fri, 19 Apr 2002 11:47:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20071;
	Fri, 19 Apr 2002 11:44:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20044
	for ; Fri, 19 Apr 2002 11:44:50 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24307
	for ; Fri, 19 Apr 2002 11:44:46 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3JFj8s06541
	for ; Fri, 19 Apr 2002 10:45:08 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Fri, 19 Apr 2002 10:44:47 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 19 Apr 2002 10:44:07 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Fri, 19 Apr 2002 10:44:06 -0500
Message-ID: 
Thread-Topic: sigcomp issue zliu-4 (MEMSET instruction)
Thread-Index: AcHnuQnboHnnKFN5EdaaMAAQpIbXLw==
To: 
X-OriginalArrivalTime: 19 Apr 2002 15:44:07.0127 (UTC) FILETIME=[0A531E70:01C1E7B9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA20045
Subject: [rohc] sigcomp issue zliu-4 (MEMSET instruction)
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

(This is probably a non-issue as most of the authors agree
on this one. But I'd like to register it here so the wider
audience is aware of it and have a chance to comment.)

During offline discussion, I've suggested to add a instruction 
MEMSET(%address, %len, %value). It is convenient for a algorithm 
that wants to set part of the UDVM buffer to a value other than 
zero. Of course, one can always do it with a loop using LOAD and
COMPARE. But that means a little larger code size and slower
execution if no compiler to compile the loop.

The feedback I got from Hans and Richard was positive (see below).
Richard further enhanced the MEMSET. I agree with him. So, does
anyone has objection? If not, I guess we can go ahead and update
the draft (before we forget about it). 

BR,
Zhigang

=================================================================
[Hans' opinion:]

> I guess the same could be achieved with a simple loop, but as 
> you say it could be more convenient to have it as an instruction. 
> 
> The UDVM currently understands 33 instructions so in my 
> opinion the cost of this addition is small.

[Richard's opinion:]

> An instruction of this type might be useful for setting up static
> dictionaries and so on. The instruction would be especially useful
> if we could vary the octets being written to the memory in some
> known manner, for example using an offset operand as follows:
> 
> MEMSET (%address, %length, %start_value, %offset)
> 
> The first octet would be set to start_value, the second octet to
> (start_value + offset) the next to (start_value + 2 * offset) etc.
> All calculations taken modulo 256, of course.

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 06:19:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20642
	for ; Mon, 22 Apr 2002 06:19:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04094;
	Mon, 22 Apr 2002 06:17:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04064
	for ; Mon, 22 Apr 2002 06:17:33 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20634
	for ; Mon, 22 Apr 2002 06:17:30 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4S18>; Mon, 22 Apr 2002 11:00:22 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFEC@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'cabo@Informatik.Uni-Bremen.DE'" ,
        zhigang.c.liu@nokia.com
Cc: Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Mon, 22 Apr 2002 11:00:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> Arguments for setting it to a small number like 2048:
> 
> -- The first message in an exchange can already download state; this
>    allows to improve compression significantly after the first
>    roundtrip.  (Otherwise, the improvement only comes after the second
>    roundtrip.)  This is essentially the "avoid negotiation" argument.

Hi,

If it's important to have a high compression ratio after one RTT, the
compressor can just download and save some state without checking that
sufficient state memory is available. The return message will include
a state_memory_size parameter; if this is set to 0 then the compressor
knows that the state creation request has failed and will not attempt
to access the state item.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 07:15:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21347
	for ; Mon, 22 Apr 2002 07:15:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06785;
	Mon, 22 Apr 2002 07:10:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06754
	for ; Mon, 22 Apr 2002 07:10:27 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21285
	for ; Mon, 22 Apr 2002 07:10:23 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4SJQ>; Mon, 22 Apr 2002 12:01:19 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFED@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Mon, 22 Apr 2002 12:01:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > Yes, we now announce both the compressed_message_size and the
> > UDVM_memory_size as a single decompression_memory_size parameter.
> > This is in line with the proposed resolution that we discussed at
> > Minneapolis.
> 
> Yes, that helps the goal of reducing the number of parameters.
> However, that makes implementation tricky on the receiver end. 
> It has to expect any combination of compressed_message_size 
> and UDVM_memory_size that totals to 2048 octets.

Hi,

In practice this should not cause any implementation problems. If an
endpoint receives a compressed message of n octets, this message is
copied into the reserved block of 2048 octets and the remaining
2048 - n octets are given to the UDVM.

> The situation is worsen by the fact that the former is for
> decompressor dispatcher and the latter is for UDVM.

The decompressor dispatcher and the UDVM are logical entities only; the
fact that both are drawing from a common pool of memory should not cause
any problems.

> How can one avoid having two buffer with 2048 octets each?

I don't believe that it is particularly difficult to use the same block
of 2048 octets to store both the compressed message and the UDVM memory.
However, if the endpoint is not memory-starved then a separate fixed-size
block of memory can easily be allocated to each one.

> Also, two related questions:
> - What will be the "special value" for UDVM_memory_size in Figure 5?

The UDVM_memory_size in Figure 5 is just set to the size of the UDVM
memory in octets (taken modulo 2^16).

> - What does decompression_memory_size mean exactly for "stream-
> compression" case?

In the stream-compression case we don't know the size of each compressed
message in advance, so we just divide the total decompression memory
equally between the input buffer and the UDVM. So if the total memory
available is 2048 octets as above, the input buffer for the compressed
data is allocated 1024 octets and the UDVM is allocated 1024 octets.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 10:26:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26791
	for ; Mon, 22 Apr 2002 10:26:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17587;
	Mon, 22 Apr 2002 10:24:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17556
	for ; Mon, 22 Apr 2002 10:24:36 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26729
	for ; Mon, 22 Apr 2002 10:24:31 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4SY5>; Mon, 22 Apr 2002 15:23:02 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF1@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: rohc@ietf.org
Date: Mon, 22 Apr 2002 15:22:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: [rohc] sigcomp issue sugar-3
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> Any reason why we don't put stack_free down in low mem as
> well? (In any case, we need to define what the terms
> "stack_free" etc. mean; the text in 9.2.3 seems to presume
> a certain location that may no longer be consistent with the
> load addresses available.) Where does the 56 come from? 

Hi,

The reason that stack_location is stored separately from
stack_free is that the former typically contains a fixed value
that will be retained between compressed messages, whereas the
latter contains a temporary value that will be reset to 0
before decompressing each message. Therefore, it is useful to
store stack_free together with the other temporary data (such
as the stack itself), outside of the memory area that will be
saved as state between compressed messages. I prefer this
mainly for "architectural reasons" as it keeps the temporary
and permanent areas of UDVM memory cleanly separated, but it
can also reduce the size of the uploaded bytecode as stack_free
does not have to be reset to 0 manually before decompressing
each message.

The value 56 is part of the following sentence:

"Decompression failure occurs if stack_free is ever decreased
below 0, or if one of the above instructions is encountered and
the value of stack_location is smaller than 56 (this prevents
the stack from overwriting the stack_location register)."

Address 56 is just the memory address immediately after the
stack_location register itself; we should probably rewrite the
above sentence to make this clear.

Regards,

Richard


--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 11:25:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28871
	for ; Mon, 22 Apr 2002 11:25:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21247;
	Mon, 22 Apr 2002 11:23:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21214
	for ; Mon, 22 Apr 2002 11:23:45 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28848
	for ; Mon, 22 Apr 2002 11:23:40 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4S8C>; Mon, 22 Apr 2002 16:20:28 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF2@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Hans Hannu (EPL)'" ,
        "'rohc@ietf.org'"
	 
Subject: RE: [rohc] sigcomp issue cabo-6
Date: Mon, 22 Apr 2002 16:20:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > The original idea in the proposed resolution was to be able to put the
> > code behind all the data.  This is no longer possible. Bug/Feature?
> 
> Why is this not possible? 
> To me the SigComp-05a approach and the approach in the issues 
> list are similar except in the way the code start address is 
> worked out.
> 
> SigComp-05a: code start address equals: the destination field * 64.
> Issues list: code start address equals: 2^(destination 
> field?) - code length.

Hi,

The new encoding for the destination field is (I hope) a feature rather
than a bug! The encoding has been updated to reflect the minimum size of
the UDVM memory.

In the first message of the session the decompression_memory_size of the
receiver is not yet known, so for safety it must be assumed that it is the
minimum value of 2048 octets. Up to 1024 octets will be reserved for the
compressed message itself, leaving a remainder of 1024 octets for the UDVM
memory.

Fortunately, 1024 octets is sufficient to store the bytecode, tables and
variables of an algorithm such as DEFLATE, together with a small circular
buffer for the previously received text strings. If more than 1024 octets
of UDVM memory happens to be available at the receiver then the algorithm
can make use of this extra memory just by increasing the size of the
circular buffer.

This means that the UDVM memory will typically be divided into 3 sections:
variables first (because they are cheaper to store in low UDVM memory),
followed by the UDVM bytecode and then by the circular buffer (which can
change size depending on the total amount of memory available to the UDVM).

The upshot of this argument is that I expect almost all bytecode uploaded
to the UDVM will be stored in the first 1024 octets of memory. Since the
SigComp header has a 4-bit destination field, it seems appropriate just to
multiply by 64 and allow the UDVM bytecode to start at any block of 64
octets up to Address 960.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 12:10:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00780
	for ; Mon, 22 Apr 2002 12:10:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25338;
	Mon, 22 Apr 2002 12:04:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25307
	for ; Mon, 22 Apr 2002 12:04:32 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00454
	for ; Mon, 22 Apr 2002 12:04:26 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3MG4JU04904;
	Mon, 22 Apr 2002 18:04:23 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Price, Richard" 
Cc: rohc@ietf.org
Subject: Re: [rohc] sigcomp issue sugar-3
References: <76C92FBBFB58D411AE760090271ED41804A0EFF1@rsys002a.roke.co.uk>
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 22 Apr 2002 18:04:17 +0200
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0EFF1@rsys002a.roke.co.uk>
Message-ID: 
Lines: 48
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi Richard,

I think some of the confusion may stem from calling the stack pointer
stack_free, when in reality we don't have a mechanism that checks
there is enough space left on the stack (i.e. there are enough "free"
locations on the stack).  Also, the notation stack[stack_free] is only
defined by example, AFAICT.

> The reason that stack_location is stored separately from
> stack_free is that the former typically contains a fixed value
> that will be retained between compressed messages, whereas the
> latter contains a temporary value that will be reset to 0
> before decompressing each message. Therefore, it is useful to
> store stack_free together with the other temporary data (such
> as the stack itself), outside of the memory area that will be
> saved as state between compressed messages. I prefer this
> mainly for "architectural reasons" as it keeps the temporary
> and permanent areas of UDVM memory cleanly separated, but it
> can also reduce the size of the uploaded bytecode as stack_free
> does not have to be reset to 0 manually before decompressing
> each message.

OK, I presume your point is that stack_free starts out at zero, so you
can implicitly initialize it by allocating it in virgin UDVM core, in
contrast to stack_location, which definitely needs to be initialized
according to the decompressor's memory layout.

> The value 56 is part of the following sentence:
> 
> "Decompression failure occurs if stack_free is ever decreased
> below 0, or if one of the above instructions is encountered and
> the value of stack_location is smaller than 56 (this prevents
> the stack from overwriting the stack_location register)."
> 
> Address 56 is just the memory address immediately after the
> stack_location register itself; we should probably rewrite the
> above sentence to make this clear.

Why is it more important to protect the stack_location register than
anything else?  In a resilient architecture, I'd imagine a stack_limit
(or stack_size) register.  Now, we don't necessarily need that, but I
still don't quite understand why my stack cannot start below 56 if I
want it to.  Is it just to have a way to detect address wraparound?

(Also note that "below 0" does not mean too much in an unsigned
arithmetic setting.)

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 12:37:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01730
	for ; Mon, 22 Apr 2002 12:37:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27712;
	Mon, 22 Apr 2002 12:35:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27669
	for ; Mon, 22 Apr 2002 12:35:43 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01595
	for ; Mon, 22 Apr 2002 12:35:39 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4TCS>; Mon, 22 Apr 2002 17:30:25 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF4@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'cabo@Informatik.Uni-Bremen.DE'" 
Cc: zhigang.c.liu@nokia.com, Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-11
Date: Mon, 22 Apr 2002 17:30:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> I.e., can we accept an implementation that always assembles a full
> message before starting the UDVM?  This would mean that a compressor
> implementation cannot rely on output being generated before the end of
> the input message is reached.  I'm not sure that fits your interesting
> model of TLS usage.

Carsten,

This is an interesting question - it depends on how we choose to define
the concepts of a "SigComp message" and a "SigComp session" in the context
of particular signalling applications.

My current assumption is that this will depend on the application security
mechanism. If security is provided by the application itself then I expect
one SigComp session to map onto exactly one application session, and one
SigComp message to map onto exactly one application message.

If security is provided by TLS I expect that one SigComp session will map
onto exactly one TLS session. However, I believe that a SigComp message
should be allowed to have an arbitrary length - it may correspond to the
entire TLS session, or it may be a standalone SigComp message that
provides feedback data only and does not carry application data at all.

In the above model the receiving endpoint can't buffer a full SigComp
message before starting the UDVM, but it can certainly buffer a full
application message (since there is no correlation between the two).
This means that the UDVM memory can be reclaimed between two application
messages, which provides similar benefits to the "instantaneous UDVM"
model used over UDP.

> We could bridge the gap by providing a "push" delimiter in the record
> marking scheme; this would make it clear that the compressor relies on
> the "persistent UDVM" model and that the UDVM needs to be started with
> the data up to the push.

I believe that the functionality of a "push" delimiter can already be
provided using the INPUT instructions.

The benefits of the "instantaneous UDVM" model can only be provided with
the co-operation of the sending endpoint, because they are only available
for certain types of compression algorithm. Stream-based algorithms (LZ77,
LZ78, LZW, DEFLATE etc.) use a constant amount of memory independently of
the application message boundaries, so there is no advantage in providing
a large UDVM core and then reclaiming this memory after each application
message has been decompressed.

With a block-based algorithm (e.g. Burrows-Wheeler) however, it is
possible to buffer an entire application message, decompress this message
and then reclaim most of the UDVM memory until the next message has fully
arrived. This can be achieved as follows:

1. The INPUT-OCTETS instruction can be used to obtain an entire application
   message, causing the UDVM to pause and wait until the message has fully
   arrived. Note that the length of the application message is carried as
   part of the compressed data (it is independent of the size of a SigComp
   message when running over TLS).

2. When the message has arrived it can be decompressed using all of the
   available UDVM memory.

3. The algorithm can place all of the data it needs to keep for the next
   application message in the low UDVM memory addresses, and it can set
   the memory it wishes to release to 0.

If a block-based algorithm of this nature is uploaded to the receiving
endpoint, any UDVM memory that it chooses to release between application
messages can be reclaimed and used elsewhere.

Note that the UDVM can still persist for the entire duration of a session,
but most of its memory can be reclaimed except for the "instantaneous"
period in which a complete application message is being decompressed.
This allows the receiving endpoint to offer a larger UDVM memory size
than would otherwise be possible.

The "push" delimiters are provided as part of the compressed data stream
by the algorithm itself (all block-based algorithms use delimiters of
some kind). Stream-based algorithms will generally not delimit the
individual application messages at all - this is useful because we can't
perform the "instantaneous UDVM" trick for an algorithm of this type, so
there is no point wasting bandwidth on delimiting the application
messages in this case.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 14:48:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08143
	for ; Mon, 22 Apr 2002 14:48:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08772;
	Mon, 22 Apr 2002 14:42:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05498
	for ; Mon, 22 Apr 2002 14:10:54 -0400 (EDT)
Received: from excore1.hns.com (excore1.hns.com [139.85.52.104])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06132
	for ; Mon, 22 Apr 2002 14:10:51 -0400 (EDT)
Received: from hns.com (altasun9.hns.com [139.85.62.38])
	by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MIANf01883;
	Mon, 22 Apr 2002 14:10:23 -0400 (EDT)
Message-ID: <3CC4520F.EBDDC34F@hns.com>
Date: Mon, 22 Apr 2002 14:10:23 -0400
From: John Border 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: rohc@ietf.org
CC: jheath@hns.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [rohc] [Fwd: I-D ACTION:draft-heath-ppp-v44-00.txt]
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit



-------- Original Message --------
Subject: I-D ACTION:draft-heath-ppp-v44-00.txt
Date: Fri, 19 Apr 2002 07:22:43 -0400
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
To: IETF-Announce: ;

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: PPP V.44/LZJH Compression Protocol
	Author(s)	: J. Heath, J. Border
	Filename	: draft-heath-ppp-v44-00.txt
	Pages		: 17
	Date		: 18-Apr-02
	
The Point-to-Point Protocol [PPP] provides a standard means for
transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [CCP] provides a means to
negotiate and utilize compression protocols over PPP encapsulated
links.
This memo describes a means for compressing PPP encapsulated 
datagrams by utilizing the data compression algorithm that is 
described in International Telecommunication Union (ITU-T) 
Recommendation V.44 [V44].  Recommendation V.44 is a modem standard 
but Annex B of the recommendation describes the implementation of
V.44 in packet networks.  This memo defines the application of V.44, 
with single or multiple compression dictionaries,to the PPP 
Compression Control Protocol (RFC 1962).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-heath-ppp-v44-00.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-heath-ppp-v44-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-heath-ppp-v44-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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:	<20020418140938.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-heath-ppp-v44-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-heath-ppp-v44-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020418140938.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 15:04:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08735
	for ; Mon, 22 Apr 2002 15:04:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10873;
	Mon, 22 Apr 2002 15:02:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10829
	for ; Mon, 22 Apr 2002 15:02:15 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08665
	for ; Mon, 22 Apr 2002 15:02:11 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MJ2Vs18036
	for ; Mon, 22 Apr 2002 14:02:32 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 22 Apr 2002 14:02:11 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 22 Apr 2002 14:01:18 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Mon, 22 Apr 2002 14:01:17 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-15
Thread-Index: AcHp5lJ+b7UK5/OuTDyhcMUnVJ8pzwAR64ng
To: , 
Cc: , 
X-OriginalArrivalTime: 22 Apr 2002 19:01:18.0305 (UTC) FILETIME=[157EDD10:01C1EA30]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA10837
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> > Arguments for setting it to a small number like 2048:
> > 
> > -- The first message in an exchange can already download state; this
> >    allows to improve compression significantly after the first
> >    roundtrip.  (Otherwise, the improvement only comes after the second
> >    roundtrip.)  This is essentially the "avoid negotiation" argument.
> 
> Hi,
>  
> If it's important to have a high compression ratio after one RTT, the
> compressor can just download and save some state without checking that
> sufficient state memory is available. The return message will include
> a state_memory_size parameter; if this is set to 0 then the compressor
> knows that the state creation request has failed and will not attempt
> to access the state item.

That works. However in case of 0 state_memroy_size, that will cost
~1K bytes overhead across the air for nothing. I still think we
can set the minimum to 1024 (with encoding 000). If that is too
much for a host, it should not use SigComp in the first place. 
It can use IPcomp.

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 16:11:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11202
	for ; Mon, 22 Apr 2002 16:11:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16271;
	Mon, 22 Apr 2002 16:09:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16238
	for ; Mon, 22 Apr 2002 16:09:47 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11154
	for ; Mon, 22 Apr 2002 16:09:42 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MK9ws22031
	for ; Mon, 22 Apr 2002 15:09:58 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 22 Apr 2002 15:09:36 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 22 Apr 2002 15:09:08 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Mon, 22 Apr 2002 15:09:08 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-15
Thread-Index: AcHp7UN1tKnS6fkyR8G6Vzm8ung3MwARw4vA
To: , , 
X-OriginalArrivalTime: 22 Apr 2002 20:09:08.0612 (UTC) FILETIME=[8F966C40:01C1EA39]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA16239
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> In practice this should not cause any implementation problems. If an
> endpoint receives a compressed message of n octets, this message is
> copied into the reserved block of 2048 octets and the remaining
> 2048 - n octets are given to the UDVM.
(snip) 
> The decompressor dispatcher and the UDVM are logical entities only; the
> fact that both are drawing from a common pool of memory should not cause
> any problems.

OK. In that case, there is no problem on the decompressor side. 

However, on the compressor side, do we have a chicken-egg problem?
The compressed message size depends on which state can be used.
On the other hand, which state can be used depends on UDVM memory
size which in turn depends on compressed message size. Of course,
the compressor can do trial-and-error. But if we have a "standalone" 
UDVM memory size, the compressor can have a fixed picture of available
UDVM memory.

> The UDVM_memory_size in Figure 5 is just set to the size of the UDVM
> memory in octets (taken modulo 2^16).

which is (2048 - n) in above example? 

> > - What does decompression_memory_size mean exactly for "stream-
> > compression" case?
> 
> In the stream-compression case we don't know the size of each compressed
> message in advance, so we just divide the total decompression memory
> equally between the input buffer and the UDVM. So if the total memory
> available is 2048 octets as above, the input buffer for the compressed
> data is allocated 1024 octets and the UDVM is allocated 1024 octets.

Does every compressor performing stream-compression must assume this? 
Considering this and above, do we really gain much by combining
compressed_message_size and UDVM_memory_size in one parameter? 

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 17:30:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14359
	for ; Mon, 22 Apr 2002 17:30:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21700;
	Mon, 22 Apr 2002 17:25:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21626
	for ; Mon, 22 Apr 2002 17:25:45 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14036
	for ; Mon, 22 Apr 2002 17:25:40 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MLPgs7002489
	for ; Mon, 22 Apr 2002 23:25:42 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 23:25:42 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 22 Apr 2002 23:15:09 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Subject: RE: [rohc] sigcomp issue sugar-6
Date: Mon, 22 Apr 2002 23:24:30 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

In attempt to closing this issue I suggest the following:

Proposed action: No action needed 

- There is no need for a STATE-FLUSH instruction.

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 17:30:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14373
	for ; Mon, 22 Apr 2002 17:30:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21690;
	Mon, 22 Apr 2002 17:25:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21621
	for ; Mon, 22 Apr 2002 17:25:45 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14035
	for ; Mon, 22 Apr 2002 17:25:39 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MLPg0E004469
	for ; Mon, 22 Apr 2002 23:25:42 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 23:25:41 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 22 Apr 2002 23:15:09 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue lejo-10
Date: Mon, 22 Apr 2002 23:24:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

In an attempt to close this issue I have the following thinking,

Proposed action: Clarify sender behaviour if S-bit is switched back to zero.

-The text of Section 9.4.7 should be update in the direction according to comments to the list:

"The sending endpoint is welcome to change its mind and switch the S-bit
back to 0 in a later message. However, the receiving endpoint is under
no obligation to use the original state_memory_size for the session; it
may choose to allocate less memory to the session or possibly none at all.

Note: The format of Figure 13 is 
only for *local* presentation of parameters on the interface between 
UDVM and state handler, NOT a format for transmission between two 
endpoints."

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 17:31:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14418
	for ; Mon, 22 Apr 2002 17:31:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21740;
	Mon, 22 Apr 2002 17:25:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21672
	for ; Mon, 22 Apr 2002 17:25:48 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14040
	for ; Mon, 22 Apr 2002 17:25:42 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MLPf0E004466
	for ; Mon, 22 Apr 2002 23:25:41 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 23:25:41 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTTAMS>; Mon, 22 Apr 2002 23:25:41 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: zhigang.c.liu@nokia.com, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Mon, 22 Apr 2002 23:24:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> That works. However in case of 0 state_memroy_size, that will cost
> ~1K bytes overhead across the air for nothing. I still think we
> can set the minimum to 1024 (with encoding 000). 

I think that we should have a default of 0 state_memory_size, with the motivation given by Carsten and Richard.

> If that is too
> much for a host, it should not use SigComp in the first place. 

Well, wouldn't you then have the discovery problem?

BR
/Hans H


> 
> BR,
> Zhigang
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 17:34:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14606
	for ; Mon, 22 Apr 2002 17:34:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22493;
	Mon, 22 Apr 2002 17:32:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22451
	for ; Mon, 22 Apr 2002 17:32:08 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14486
	for ; Mon, 22 Apr 2002 17:32:01 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MLW20E005077
	for ; Mon, 22 Apr 2002 23:32:02 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 23:32:02 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 22 Apr 2002 23:21:29 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue rp-8
Date: Mon, 22 Apr 2002 23:30:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

I'm not sure if I add anything new to this discussion but, I still like to say in order to try closing this issue:

Proposed action: Add STATE-CREATE instruction if time limit allows for security consideration redo
Limit the number of created states by one compressed message to a maximum of 4.

BR
/Hans H

> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: den 17 april 2002 18:28
> To: 'zhigang.c.liu@nokia.com'; Hans.Hannu@epl.ericsson.se; 
> rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue rp-8
> 
...
> 
> If it turns out that STATE-CREATE introduces only a 
> negligible additional
> security risk then I'd like to see the functionality added to 
> SigComp-06.
...
> Regards,
> 
> Richard
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 17:39:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14944
	for ; Mon, 22 Apr 2002 17:39:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22810;
	Mon, 22 Apr 2002 17:38:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22771
	for ; Mon, 22 Apr 2002 17:38:01 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14788
	for ; Mon, 22 Apr 2002 17:37:54 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MLbh0E005461
	for ; Mon, 22 Apr 2002 23:37:43 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 23:37:42 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 22 Apr 2002 23:27:10 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
Date: Mon, 22 Apr 2002 23:36:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

With this still in my mind the discussion we have had seems to lead to the following proposed action.

Proposed action: Add STATE-FREE instruction

We need to make sure that the text about this instruction includes the following in some way.
(Cut from previous mails regarding this issue)

"STATE-FREE is simply to allow the compressor to say "I'm not going to use a state I created before"

1) check if the compressor has requested to create the state to be 
freed in the past. If not, invalid STATE_FREE, stop.
2) deduct the size of the freed state from the state_memory size for 
the compressor
3) decrement the counter associated with the freed state by 1. 
(Note, the counter of a state is incremented whenever a compressor 
requests to create a state that has already been created)
4) if the counter reaches 0, physically delete the state."

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 22 17:52:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15716
	for ; Mon, 22 Apr 2002 17:52:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23510;
	Mon, 22 Apr 2002 17:47:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23483
	for ; Mon, 22 Apr 2002 17:47:48 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15388
	for ; Mon, 22 Apr 2002 17:47:14 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MLlFs7004105
	for ; Mon, 22 Apr 2002 23:47:15 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 23:47:14 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 22 Apr 2002 23:36:42 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Mon, 22 Apr 2002 23:46:03 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

Perhaps I'm way out on deep water but is it possible to change cycles_per_bit in case we find that unreasonable high after interOp tests have started? Or should we do the opposite put a lower value say cycles_per_bit: 8 and increase it if interOp tests indicate the need?

Good night,
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 05:26:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09905
	for ; Tue, 23 Apr 2002 05:26:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11271;
	Tue, 23 Apr 2002 05:24:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11243
	for ; Tue, 23 Apr 2002 05:23:57 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09879
	for ; Tue, 23 Apr 2002 05:23:48 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4T5D>; Tue, 23 Apr 2002 10:18:32 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF5@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" ,
        cabo@Informatik.Uni-Bremen.DE
Cc: Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Tue, 23 Apr 2002 10:18:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > > Arguments for setting it to a small number like 2048:
> > > 
> > > -- The first message in an exchange can already download state; this
> > >    allows to improve compression significantly after the first
> > >    roundtrip.  (Otherwise, the improvement only comes after the second
> > >    roundtrip.)  This is essentially the "avoid negotiation" argument.
> > 
> > If it's important to have a high compression ratio after one RTT, the
> > compressor can just download and save some state without checking that
> > sufficient state memory is available. The return message will include
> > a state_memory_size parameter; if this is set to 0 then the compressor
> > knows that the state creation request has failed and will not attempt
> > to access the state item.
> 
> That works. However in case of 0 state_memroy_size, that will cost
> ~1K bytes overhead across the air for nothing.

Hi,

I don't see why any bandwidth needs to be wasted if the state_memory_size is 0.
Most of the ~1K state item is taken up by text strings from the decompressed
message; these have to be transmitted regardless of whether they will be saved
as state or not.

> I still think we can set the minimum to 1024 (with encoding 000).
> If that is too much for a host, it should not use SigComp in the
> first place. It can use IPcomp.

Choosing between SigComp and IPcomp would require a discovery mechanism, which
I'm keen to avoid if possible.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 06:53:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11244
	for ; Tue, 23 Apr 2002 06:53:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16159;
	Tue, 23 Apr 2002 06:43:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16127
	for ; Tue, 23 Apr 2002 06:43:09 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10973
	for ; Tue, 23 Apr 2002 06:43:03 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4T0V>; Tue, 23 Apr 2002 11:22:24 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF6@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Hans Hannu (EPL)'" ,
        "'rohc@ietf.org'"
	 
Subject: RE: [rohc] sigcomp issue sugar-6
Date: Tue, 23 Apr 2002 11:22:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

I also believe that we can close the issue sugar-6 because
the S-bit provides the same functionality as a STATE-FLUSH
instruction.

It would be useful to add more explanation of exactly how the
S-bit influences the behaviour of the sender and the receiver,
but this is covered separately by the issue lejo-10.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se]
> Sent: Monday, April 22, 2002 10:25 PM
> To: 'rohc@ietf.org'
> Subject: RE: [rohc] sigcomp issue sugar-6
> 
> 
> Hi,
> 
> In attempt to closing this issue I suggest the following:
> 
> Proposed action: No action needed 
> 
> - There is no need for a STATE-FLUSH instruction.
> 
> BR
> /Hans H
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 08:43:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15014
	for ; Tue, 23 Apr 2002 08:43:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26282;
	Tue, 23 Apr 2002 08:34:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26247
	for ; Tue, 23 Apr 2002 08:34:00 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14492
	for ; Tue, 23 Apr 2002 08:33:56 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R44HT>; Tue, 23 Apr 2002 13:31:10 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF7@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'cabo@Informatik.Uni-Bremen.DE'" 
Cc: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue sugar-3
Date: Tue, 23 Apr 2002 13:31:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> I think some of the confusion may stem from calling the stack pointer
> stack_free, when in reality we don't have a mechanism that checks
> there is enough space left on the stack (i.e. there are enough "free"
> locations on the stack).  Also, the notation stack[stack_free] is only
> defined by example, AFAICT.

Hi Carsten,

The terms stack_free and stack[n] are defined in Section 8.3, although
not in a particularly formal manner. If any of the terminology is
misleading or if a more formal definition would be useful then we can
easily update this section as needed.

> > The reason that stack_location is stored separately from
> > stack_free is that the former typically contains a fixed value
> > that will be retained between compressed messages, whereas the
> > latter contains a temporary value that will be reset to 0
> > before decompressing each message. Therefore, it is useful to
> > store stack_free together with the other temporary data (such
> > as the stack itself), outside of the memory area that will be
> > saved as state between compressed messages. I prefer this
> > mainly for "architectural reasons" as it keeps the temporary
> > and permanent areas of UDVM memory cleanly separated, but it
> > can also reduce the size of the uploaded bytecode as stack_free
> > does not have to be reset to 0 manually before decompressing
> > each message.
> 
> OK, I presume your point is that stack_free starts out at zero, so you
> can implicitly initialize it by allocating it in virgin UDVM core, in
> contrast to stack_location, which definitely needs to be initialized
> according to the decompressor's memory layout.

Precisely.

> > The value 56 is part of the following sentence:
> > 
> > "Decompression failure occurs if stack_free is ever decreased
> > below 0, or if one of the above instructions is encountered and
> > the value of stack_location is smaller than 56 (this prevents
> > the stack from overwriting the stack_location register)."
> > 
> > Address 56 is just the memory address immediately after the
> > stack_location register itself; we should probably rewrite the
> > above sentence to make this clear.
> 
> Why is it more important to protect the stack_location register than
> anything else?  In a resilient architecture, I'd imagine a stack_limit
> (or stack_size) register.  Now, we don't necessarily need that, but I
> still don't quite understand why my stack cannot start below 56 if I
> want it to.  Is it just to have a way to detect address wraparound?

The problem with overwriting the stack_location register is just that
the addresses of the 2-octet words stack_free and stack[n] depend on
the value contained in stack_location. So if stack_location is
overwritten then the behaviour of the PUSH, POP, CALL and RETURN
instructions may become unpredictable.

If we want to allow the stack to overwrite its own stack_location then
we need to define precisely how the above instructions function in this
situation: namely the point at which the addresses of stack_free and
stack[n] change to reflect the new value of stack_location.

> (Also note that "below 0" does not mean too much in an unsigned
> arithmetic setting.)

Ok, replace this with "if stack_free is ever decreased when it is
already 0" or something similar.

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 09:10:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16189
	for ; Tue, 23 Apr 2002 09:10:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28398;
	Tue, 23 Apr 2002 09:05:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28345
	for ; Tue, 23 Apr 2002 09:05:36 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15899
	for ; Tue, 23 Apr 2002 09:05:32 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (IDENT:CK6B/tHVWdrIYqhdsQCXKBIxr7KhLJXd@roman.informatik.uni-bremen.de [134.102.218.120])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3ND5RV03351;
	Tue, 23 Apr 2002 15:05:29 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Price, Richard" 
Cc: rohc@ietf.org
Subject: Re: [rohc] sigcomp issue sugar-3
References: <76C92FBBFB58D411AE760090271ED41804A0EFF7@rsys002a.roke.co.uk>
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 23 Apr 2002 15:05:24 +0200
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0EFF7@rsys002a.roke.co.uk>
Message-ID: 
Lines: 26
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

"Price, Richard"  writes:

> The problem with overwriting the stack_location register is just that
> the addresses of the 2-octet words stack_free and stack[n] depend on
> the value contained in stack_location. So if stack_location is
> overwritten then the behaviour of the PUSH, POP, CALL and RETURN
> instructions may become unpredictable.

That would be fine, I believe.
Do we have to define the precise outcome in all error situations?
(Cf. DIVIDE by zero...)

I we want to be predictable and safe, "overwritten in the course of
PUSH, POP, CALL, RETURN" could be the cause for DECOMPRESSION_FAILURE.
More code for the implementers (another memory cell to protect).

> If we want to allow the stack to overwrite its own stack_location then
> we need to define precisely how the above instructions function in this
> situation: namely the point at which the addresses of stack_free and
> stack[n] change to reflect the new value of stack_location.

Again, I would be happy with "unpredictable", but we actually could go
ahead and define the "RTL" for these four instructions, i.e. the
precise sequence of events.

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 09:10:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16236
	for ; Tue, 23 Apr 2002 09:10:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28366;
	Tue, 23 Apr 2002 09:05:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28308
	for ; Tue, 23 Apr 2002 09:05:33 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15897
	for ; Tue, 23 Apr 2002 09:05:29 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R44K4>; Tue, 23 Apr 2002 14:02:50 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF8@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Hans Hannu (EPL)'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Tue, 23 Apr 2002 14:02:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

We should probably err on the side of caution and set cycles_per_bit
to a high value rather than a low value. If the minimum value turns
out to be twice as much as is needed for DEFLATE then I can't see any
serious problems for implementers. However, if the minimum value
turns out to be less than is required to run a typical decompression
algorithm then we will be unable to upload many algorithms for a full
RTT while waiting for a more sensible cycles_per_bit to be announced
by the receiving endpoint.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se]
> Sent: Monday, April 22, 2002 10:46 PM
> To: rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue cabo-15
> 
> 
> Hi,
> 
> Perhaps I'm way out on deep water but is it possible to 
> change cycles_per_bit in case we find that unreasonable high 
> after interOp tests have started? Or should we do the 
> opposite put a lower value say cycles_per_bit: 8 and increase 
> it if interOp tests indicate the need?
> 
> Good night,
> /Hans H
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 09:59:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18071
	for ; Tue, 23 Apr 2002 09:59:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01625;
	Tue, 23 Apr 2002 09:53:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01591
	for ; Tue, 23 Apr 2002 09:53:12 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17825
	for ; Tue, 23 Apr 2002 09:53:07 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R443L>; Tue, 23 Apr 2002 14:41:13 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFF9@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Hans Hannu (EPL)'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue rp-8
Date: Tue, 23 Apr 2002 14:41:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

One final question on this issue: if we determine that a
STATE-CREATE instruction is OK from a security perspective
then should we delete the ability to create a state item from
the END-MESSAGE instruction? This will simplify the draft
somewhat, but on the other hand the UDVM bytecode for a
typical decompression algorithm will cost 1 additional octet.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:Hans.Hannu@epl.ericsson.se]
> Sent: Monday, April 22, 2002 10:31 PM
> To: rohc@ietf.org
> Subject: RE: [rohc] sigcomp issue rp-8
> 
> 
> Hi,
> 
> I'm not sure if I add anything new to this discussion but, I 
> still like to say in order to try closing this issue:
> 
> Proposed action: Add STATE-CREATE instruction if time limit 
> allows for security consideration redo
> Limit the number of created states by one compressed message 
> to a maximum of 4.
> 
> BR
> /Hans H
> 
> > -----Original Message-----
> > From: Price, Richard [mailto:richard.price@roke.co.uk]
> > Sent: den 17 april 2002 18:28
> > To: 'zhigang.c.liu@nokia.com'; Hans.Hannu@epl.ericsson.se; 
> > rohc@ietf.org
> > Subject: RE: [rohc] sigcomp issue rp-8
> > 
> ...
> > 
> > If it turns out that STATE-CREATE introduces only a 
> > negligible additional
> > security risk then I'd like to see the functionality added to 
> > SigComp-06.
> ...
> > Regards,
> > 
> > Richard
> > 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 10:02:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18176
	for ; Tue, 23 Apr 2002 10:02:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01939;
	Tue, 23 Apr 2002 09:59:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01909
	for ; Tue, 23 Apr 2002 09:59:32 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18064
	for ; Tue, 23 Apr 2002 09:59:26 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3NDxR0E020331
	for ; Tue, 23 Apr 2002 15:59:27 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 23 15:59:27 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Apr 2002 15:48:53 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'Price, Richard'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Tue, 23 Apr 2002 15:42:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> We should probably err on the side of caution and set cycles_per_bit
> to a high value rather than a low value. If the minimum value turns
> out to be twice as much as is needed for DEFLATE then I can't see any
> serious problems for implementers. However, if the minimum value
> turns out to be less than is required to run a typical decompression
> algorithm then we will be unable to upload many algorithms for a full
> RTT while waiting for a more sensible cycles_per_bit to be announced
> by the receiving endpoint.

This seems to be good reasoning. 

So is it ok to say the following then?

Proposed action: Resolution proposed in current editor's working document (This text seems to be sufficient.) 
Suggested default values seems to be well motivated. 

(Cut from previous mails)
"decompression_memory_size: 2048 octets
state_memory_size: 0 octets
cycles_per_bit: 16
SigComp_version: 0
locally available state: none"

BR
/Hans H



_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 10:18:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18849
	for ; Tue, 23 Apr 2002 10:18:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03047;
	Tue, 23 Apr 2002 10:17:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03012
	for ; Tue, 23 Apr 2002 10:17:02 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18747
	for ; Tue, 23 Apr 2002 10:16:56 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3NEGv0E000705
	for ; Tue, 23 Apr 2002 16:16:57 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 23 16:16:53 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBT4D9W>; Tue, 23 Apr 2002 16:16:53 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'Price, Richard'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue rp-8
Date: Tue, 23 Apr 2002 15:59:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> One final question on this issue: if we determine that a
> STATE-CREATE instruction is OK from a security perspective
> then should we delete the ability to create a state item from
> the END-MESSAGE instruction? This will simplify the draft
> somewhat, but on the other hand the UDVM bytecode for a
> typical decompression algorithm will cost 1 additional octet.

Hi Richard,

I kind of like the END-MESSAGE instruction as it is today. So my suggestion is to leave the END-MESSAGE instruction as it is in the current editor's working document. 

However, the question still exist whether STATE-CREATE with a limit of 4 (or even fewer) state creates is OK from a security perspective or not. I do not have the answer and it seems that nobody are convinced either way (myself included). Anybody?

BR,
/Hans H
 


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 10:31:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19557
	for ; Tue, 23 Apr 2002 10:31:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03521;
	Tue, 23 Apr 2002 10:26:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03449
	for ; Tue, 23 Apr 2002 10:26:14 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19180
	for ; Tue, 23 Apr 2002 10:26:10 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (IDENT:WNvXL/D2xFtk5lCofoixXQ+SA2mUzkEZ@roman.informatik.uni-bremen.de [134.102.218.120])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3NEPjV24039;
	Tue, 23 Apr 2002 16:25:52 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Price, Richard" 
Cc: "'Hans Hannu (EPL)'" , rohc@ietf.org
Subject: Re: [rohc] sigcomp issue rp-8
References: <76C92FBBFB58D411AE760090271ED41804A0EFF9@rsys002a.roke.co.uk>
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 23 Apr 2002 16:25:43 +0200
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0EFF9@rsys002a.roke.co.uk>
Message-ID: 
Lines: 27
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

"Price, Richard"  writes:

> Hi,
> 
> One final question on this issue: if we determine that a
> STATE-CREATE instruction is OK from a security perspective
> then should we delete the ability to create a state item from
> the END-MESSAGE instruction? This will simplify the draft
> somewhat, but on the other hand the UDVM bytecode for a
> typical decompression algorithm will cost 1 additional octet.

One more question about STATE-CREATE:
What is the sequence of events with respect to the application
agreeing on the creation of the state?
In other words, how does STATE-CREATE consume buffer size
(decompression_memory_size)?
We can't really have it consume state_memory_size, because we don't
know the compartment ID yet at the time the UDVM still runs, so we
don't know how much of that is left (and where to delete old state).
Or is STATE-CREATE just leaving behind pointers into UDVM core that
will be processed at END-MESSAGE time?

(BTW, you might get back the byte at the time the last message in a
sequence gets compressed -- this may not have to create further state,
saving the space for the pertinent parameters of END-MESSAGE.)

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 10:34:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19721
	for ; Tue, 23 Apr 2002 10:34:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03811;
	Tue, 23 Apr 2002 10:30:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03770
	for ; Tue, 23 Apr 2002 10:30:12 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19474
	for ; Tue, 23 Apr 2002 10:30:06 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3NEU60E008357
	for ; Tue, 23 Apr 2002 16:30:07 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 23 16:29:50 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Apr 2002 16:19:16 +0200
Message-ID: 
From: "Jan Christoffersson (EPL)" 
To: "'Price, Richard'" ,
        "'cabo@Informatik.Uni-Bremen.DE'" 
Cc: zhigang.c.liu@nokia.com, "Hans Hannu (EPL)"
	 ,
        rohc@ietf.org
Subject: RE: [rohc] sigcomp issue cabo-11
Date: Tue, 23 Apr 2002 16:12:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Carsten,
from (part of) Richards answer to your suggestion in cabo-11 it seems as this issue can be closed. Is this correct or are there still outstanding questions with this issue?
/Jan


> > We could bridge the gap by providing a "push" delimiter in the record
> > marking scheme; this would make it clear that the compressor relies on
> > the "persistent UDVM" model and that the UDVM needs to be started with
> > the data up to the push.

> I believe that the functionality of a "push" delimiter can already be
> provided using the INPUT instructions.


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 10:51:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20646
	for ; Tue, 23 Apr 2002 10:51:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05006;
	Tue, 23 Apr 2002 10:46:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04953
	for ; Tue, 23 Apr 2002 10:46:49 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20237
	for ; Tue, 23 Apr 2002 10:46:43 -0400 (EDT)
Received: from localhost.tzi.org.informatik.uni-bremen.de (IDENT:2eNZoMaS/h2FpfJd4fMspVK7p6Bs/Pl2@roman.informatik.uni-bremen.de [134.102.218.120])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3NEkZV28776;
	Tue, 23 Apr 2002 16:46:37 +0200 (MEST)
X-Mailer: emacs 21.2.1 (via feedmail 8 I)
To: "Hans Hannu (EPL)" 
Cc: rohc@ietf.org
Subject: Re: [rohc] sigcomp issue sugar-5/cabo-8
References: 
From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)
Date: 23 Apr 2002 16:46:34 +0200
In-Reply-To: 
Message-ID: 
Lines: 40
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

"Hans Hannu (EPL)"  writes:

> Hi,
> 
> With this still in my mind the discussion we have had seems to lead to the following proposed action.
> 
> Proposed action: Add STATE-FREE instruction
> 
> We need to make sure that the text about this instruction includes the following in some way.
> (Cut from previous mails regarding this issue)
> 
> "STATE-FREE is simply to allow the compressor to say "I'm not going to use a state I created before"
> 
> 1) check if the compressor has requested to create the state to be 
> freed in the past. If not, invalid STATE_FREE, stop.

Hmm, how do you check this in the presence of packet losses and
retransmissions?  Do you need to keep a history even after deletion?
If yes, what is the bound on the history?

It seems we must allow a STATE-FREE on anything.

> 2) deduct the size of the freed state from the state_memory size for 
> the compressor

This step, of course, is not executed if the state isn't still being
referenced (maybe you meant this by "stop").

> 3) decrement the counter associated with the freed state by 1. 
> (Note, the counter of a state is incremented whenever a compressor 
> requests to create a state that has already been created)

Hmm, packet loss/retransmissions again.
The counter should only be increased if the state has newly entered
the set of state associated with this session/compartment.
Repeated STATE-CREATE for the same session/compartment should not count.

> 4) if the counter reaches 0, physically delete the state."

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 11:59:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24821
	for ; Tue, 23 Apr 2002 11:59:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10436;
	Tue, 23 Apr 2002 11:57:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10396
	for ; Tue, 23 Apr 2002 11:57:43 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24683
	for ; Tue, 23 Apr 2002 11:57:38 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R44Y6>; Tue, 23 Apr 2002 16:52:46 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFFA@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'cabo@Informatik.Uni-Bremen.DE'" 
Cc: "'Hans Hannu (EPL)'" , rohc@ietf.org
Subject: RE: [rohc] sigcomp issue rp-8
Date: Tue, 23 Apr 2002 16:52:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> One more question about STATE-CREATE:
> What is the sequence of events with respect to the application
> agreeing on the creation of the state?

Hi,

The application can't agree to create new state until the END-MESSAGE
instruction is reached, at which point the complete decompressed
message is available. All that can be done before this point is to
identify the areas of UDVM memory that will be saved as state, assuming
that permission is granted by the application.

> In other words, how does STATE-CREATE consume buffer size
> (decompression_memory_size)?
> We can't really have it consume state_memory_size, because we don't
> know the compartment ID yet at the time the UDVM still runs, so we
> don't know how much of that is left (and where to delete old state).
> Or is STATE-CREATE just leaving behind pointers into UDVM core that
> will be processed at END-MESSAGE time?

A new state item can be created by supplying the following 5 operands:

state_length
state_address
state_instruction
minimum_access_length
state_retention_priority

The total cost of storing this data is just 10 octets; the state_value
and the state_identifier do not need to be specified as operands
because they can be found in the UDVM memory at END-MESSAGE time.

A STATE-CREATE instruction would buffer the above 10 octets until the
message has been successfully decompressed, at which point the state_value
and the state_identifier can be obtained from the UDVM memory. So the cost
of buffering 4 STATE-CREATE instructions is just 40 octets; I don't
believe we need to subtract this from the decompression_memory_size
because 40 octets are negligible even for a memory-starved implementation.

> (BTW, you might get back the byte at the time the last message in a
> sequence gets compressed -- this may not have to create further state,
> saving the space for the pertinent parameters of END-MESSAGE.)

It's probably too late to update the END-MESSAGE instruction by then,
because all of the operands will have been uploaded to the receiving
endpoint and saved as state.

I believe that we should allow the END-MESSAGE instruction to create
one state item, and then use a specific STATE-CREATE instruction to
create extra state items up to a fixed maximum limit. This approach
nicely mirrors the situation for accessing state (we can access one
state item "for free" using the SigComp header, and can access further
state items by using a specific STATE-ACCESS instruction).

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 12:00:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24859
	for ; Tue, 23 Apr 2002 12:00:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10067;
	Tue, 23 Apr 2002 11:54:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10036
	for ; Tue, 23 Apr 2002 11:54:00 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24499
	for ; Tue, 23 Apr 2002 11:53:54 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3NFuhH02590
	for ; Tue, 23 Apr 2002 10:56:43 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 23 Apr 2002 08:53:57 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 23 Apr 2002 10:53:57 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Tue, 23 Apr 2002 10:53:56 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-15
Thread-Index: AcHqqB6JrLV+v6CZRWmWZiNnUk8fowAM6nGA
To: , 
Cc: , 
X-OriginalArrivalTime: 23 Apr 2002 15:53:57.0097 (UTC) FILETIME=[13A06590:01C1EADF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA10037
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> Most of the ~1K state item is taken up by text strings from 
> the decompressed message; 

This is not necessarily true. The ~1K state can contain anything. 
Specifically, the compressor may want to pre-populate the
dictionary with text that not even appears in current message
on which the state creation request is piggybacked on. 

> > I still think we can set the minimum to 1024 (with encoding 000).
> > If that is too much for a host, it should not use SigComp in the
> > first place. It can use IPcomp.
> 
> Choosing between SigComp and IPcomp would require a discovery 
> mechanism, which I'm keen to avoid if possible.

What I'm trying to say is that one of the advantages of SigComp
over IPcomp is the dictionary based compression. And that is the
reason why a host chooses SigComp. Setting the default to 0
seems defeating the purpose of SigComp.

Re discovery, that is a separate issue. The general SigComp
discovery is an open problem anyway, regardless if IPcomp is 
in picture. (We managed to avoid it in 3GPP by mandating support 
for SigComp. But that is just a quick fix due to time pressure)

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 12:15:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25594
	for ; Tue, 23 Apr 2002 12:15:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12811;
	Tue, 23 Apr 2002 12:10:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12777
	for ; Tue, 23 Apr 2002 12:09:59 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25335
	for ; Tue, 23 Apr 2002 12:09:53 -0400 (EDT)
Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3NG9pV17247;
	Tue, 23 Apr 2002 18:09:51 +0200 (MEST)
Message-ID: <3CC5874A.4010201@tzi.org>
Date: Tue, 23 Apr 2002 18:09:46 +0200
From: Carsten Bormann 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Price, Richard" 
CC: "'cabo@Informatik.Uni-Bremen.DE'" ,
        "'Hans
 Hannu (EPL)'" , rohc@ietf.org
Subject: Re: [rohc] sigcomp issue rp-8
References: <76C92FBBFB58D411AE760090271ED41804A0EFFA@rsys002a.roke.co.uk>
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit

Price, Richard wrote:
> The total cost of storing this data is just 10 octets; the state_value
> and the state_identifier do not need to be specified as operands
> because they can be found in the UDVM memory at END-MESSAGE time.

Sounds good to me (well, actually, 9 octets, but that's quibbling).

> I believe that we should allow the END-MESSAGE instruction to create
> one state item, and then use a specific STATE-CREATE instruction to
> create extra state items up to a fixed maximum limit. This approach
> nicely mirrors the situation for accessing state (we can access one
> state item "for free" using the SigComp header, and can access further
> state items by using a specific STATE-ACCESS instruction).

The purist in me doesn't like this too much, but then I probably don't 
care too much either.  So let's go forward with this.

Since you already wrote 80 % of what's needed:
Can you send me the text to put into the document?

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 23 12:40:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26860
	for ; Tue, 23 Apr 2002 12:40:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14468;
	Tue, 23 Apr 2002 12:33:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14437
	for ; Tue, 23 Apr 2002 12:33:18 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26627
	for ; Tue, 23 Apr 2002 12:33:15 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R446H>; Tue, 23 Apr 2002 17:30:37 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFFB@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'cabo@Informatik.Uni-Bremen.DE'" 
Cc: rohc@ietf.org
Subject: RE: [rohc] sigcomp issue sugar-3
Date: Tue, 23 Apr 2002 17:30:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> "Price, Richard"  writes:
> 
> > The problem with overwriting the stack_location register is just that
> > the addresses of the 2-octet words stack_free and stack[n] depend on
> > the value contained in stack_location. So if stack_location is
> > overwritten then the behaviour of the PUSH, POP, CALL and RETURN
> > instructions may become unpredictable.
> 
> That would be fine, I believe.
> Do we have to define the precise outcome in all error situations?
> (Cf. DIVIDE by zero...)

My concern with not defining the outcome of all error situations is that
implementers may fail to spot that the error can occur, and as a result
they may fail to take adequate security protections against buffer
overflow attacks and so forth.

Moreover, the only reason that an error condition will occur is because
the bytecode has been messed up (either accidentally or maliciously). In
an unsecured environment it's probably wise to call a decompression failure
in this case (same goes for DIVIDE by zero).

> I we want to be predictable and safe, "overwritten in the course of
> PUSH, POP, CALL, RETURN" could be the cause for DECOMPRESSION_FAILURE.
> More code for the implementers (another memory cell to protect).
>
> > If we want to allow the stack to overwrite its own stack_location then
> > we need to define precisely how the above instructions function in this
> > situation: namely the point at which the addresses of stack_free and
> > stack[n] change to reflect the new value of stack_location.
> 
> Again, I would be happy with "unpredictable", but we actually could go
> ahead and define the "RTL" for these four instructions, i.e. the
> precise sequence of events.

Assuming that we want to store the stack in low memory, I'd be marginally
happier if we call a decompression failure when the stack overwrites its
own stack_location. However, any solution is fine provided that it isn't
along the lines of "crash horribly and corrupt the memory for the entire
endpoint"!

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 05:58:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28649
	for ; Wed, 24 Apr 2002 05:58:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16843;
	Wed, 24 Apr 2002 05:52:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16811
	for ; Wed, 24 Apr 2002 05:52:57 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28599
	for ; Wed, 24 Apr 2002 05:52:44 -0400 (EDT)
Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2VH2WCS0>; Wed, 24 Apr 2002 10:30:18 +0100
Received: from roke.co.uk (percy.roke.co.uk [193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2V2R4VS9; Wed, 24 Apr 2002 10:30:14 +0100
From: "West, Mark (ITN)" 
To: "Price, Richard" 
Cc: "'cabo@Informatik.Uni-Bremen.DE'" ,
        rohc@ietf.org
Message-ID: <3CC67B1C.3030801@roke.co.uk>
Date: Wed, 24 Apr 2002 10:30:04 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
Subject: Re: [rohc] sigcomp issue sugar-3
References: <76C92FBBFB58D411AE760090271ED41804A0EFFB@rsys002a.roke.co.uk>
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Hi all,

Throwing in a couple of points from an implementer...

>>
>>
>>>The problem with overwriting the stack_location register is just that
>>>the addresses of the 2-octet words stack_free and stack[n] depend on
>>>the value contained in stack_location. So if stack_location is
>>>overwritten then the behaviour of the PUSH, POP, CALL and RETURN
>>>instructions may become unpredictable.
>>>
>>That would be fine, I believe.
>>Do we have to define the precise outcome in all error situations?
>>(Cf. DIVIDE by zero...)
>>
> 
> My concern with not defining the outcome of all error situations is that
> implementers may fail to spot that the error can occur, and as a result
> they may fail to take adequate security protections against buffer
> overflow attacks and so forth.


This is obviously a concern.  However, trying to circumscribe all error 
cases (other than by listing the complete set of all allowable UDVM 
programs ;-) can be long-winded.  (Both for the spec. and the program)

I understood that the intent was more to ensure that the VM ran in a 
*very* constrained 'sandbox' with extremely limited interface to the 
outside world (and tight bounds on how much resources it is allowed to 
consume).

Provided that implementers nail these key aspects down, anything else is 
just an optimisation..?  It's keeping the interface simple & 
well-defined that helps.

> 
> Moreover, the only reason that an error condition will occur is because
> the bytecode has been messed up (either accidentally or maliciously). In
> an unsecured environment it's probably wise to call a decompression failure
> in this case (same goes for DIVIDE by zero).
> 


This is obviously sensible.  However, provided that 'undefined' can 
include 'decompression failure', then it is allowable for a UDVM to 
react in this way.  (So do we need to mandate it..?  In all cases..?)


> 
>>I we want to be predictable and safe, "overwritten in the course of
>>PUSH, POP, CALL, RETURN" could be the cause for DECOMPRESSION_FAILURE.
>>More code for the implementers (another memory cell to protect).
>>


Avoiding code sounds good...


>>
>>>If we want to allow the stack to overwrite its own stack_location then
>>>we need to define precisely how the above instructions function in this
>>>situation: namely the point at which the addresses of stack_free and
>>>stack[n] change to reflect the new value of stack_location.
>>>
>>Again, I would be happy with "unpredictable", but we actually could go
>>ahead and define the "RTL" for these four instructions, i.e. the
>>precise sequence of events.
>>
> 
> Assuming that we want to store the stack in low memory, I'd be marginally
> happier if we call a decompression failure when the stack overwrites its
> own stack_location. However, any solution is fine provided that it isn't
> along the lines of "crash horribly and corrupt the memory for the entire
> endpoint"!
> 


This, I guess, is what I meant about the sandbox thing -- I don't think 
that it should be possible for the UDVM to access the memory in the 
endpoint, other than through the well-defined instruction interfaces. 
If it wants to trash the VM stack, that's fine (well, you know what I mean!)

An implementation may be considered 'better' if it stops promptly on 
detection of weird stuff happenning, but it shouldn't matter, particularly.


> Regards,
> 
> Richard
> 
> 


Cheers,

Mark.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 11:56:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19997
	for ; Wed, 24 Apr 2002 11:56:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10062;
	Wed, 24 Apr 2002 11:50:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10031
	for ; Wed, 24 Apr 2002 11:50:34 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19908
	for ; Wed, 24 Apr 2002 11:50:29 -0400 (EDT)
Received: from tzi.org (IDENT:pHI1CZ7iEDenFySqjfVBsKv3jbe0xAns@roman.informatik.uni-bremen.de [134.102.218.120])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3OFoP100187;
	Wed, 24 Apr 2002 17:50:25 +0200 (MEST)
Message-ID: <3CC6D442.7060409@tzi.org>
Date: Wed, 24 Apr 2002 17:50:26 +0200
From: Carsten Bormann 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Price, Richard" 
CC: "'cabo@Informatik.Uni-Bremen.DE'" ,
        rohc@ietf.org
Subject: Re: [rohc] sigcomp issue sugar-3
References: <76C92FBBFB58D411AE760090271ED41804A0EFFB@rsys002a.roke.co.uk>
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit

> Moreover, the only reason that an error condition will occur is because
> the bytecode has been messed up (either accidentally or maliciously). In
> an unsecured environment it's probably wise to call a decompression failure
> in this case (same goes for DIVIDE by zero).

Having thought more about this, DIVIDE (or REMAINDER) by zero is a 
condition that an implementation already has to check for on many 
architectures (to avoid crashing and burning themselves), so I have 
added text that makes this a DECOMPRESSION-FAILURE.

> Assuming that we want to store the stack in low memory, I'd be marginally
> happier if we call a decompression failure when the stack overwrites its
> own stack_location. However, any solution is fine provided that it isn't
> along the lines of "crash horribly and corrupt the memory for the entire
> endpoint"!

Based on Mark's message today, I propose the new text I just checked in, 
which makes the behavior in this case unpredictable (and encourages 
DECOMPRESSION-FAILURE in a "checking" implementation).  It also defines 
the stack in (I hope) a slightly more rigorous manner.

Comments?

I'd like to move this to "Resolution proposed in current editors' 
working document".

Gruesse, Carsten



_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 12:17:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21139
	for ; Wed, 24 Apr 2002 12:17:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12922;
	Wed, 24 Apr 2002 12:12:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12873
	for ; Wed, 24 Apr 2002 12:12:26 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21057
	for ; Wed, 24 Apr 2002 12:12:21 -0400 (EDT)
Received: from tzi.org (IDENT:PQIw8f8LCEGdVyGuhX3vIqbDy+I+Rg56@roman.informatik.uni-bremen.de [134.102.218.120])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3OGCE105445;
	Wed, 24 Apr 2002 18:12:15 +0200 (MEST)
Message-ID: <3CC6D960.1000508@tzi.org>
Date: Wed, 24 Apr 2002 18:12:16 +0200
From: Carsten Bormann 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Price, Richard" 
CC: "'cabo@Informatik.Uni-Bremen.DE'" ,
        zhigang.c.liu@nokia.com, Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: Re: [rohc] sigcomp issue cabo-11
References: <76C92FBBFB58D411AE760090271ED41804A0EFF4@rsys002a.roke.co.uk>
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit

> any UDVM memory that it chooses to release between application
> messages 

Richard,

I'm not sure I understand this.
What do you mean by "releasing UDVM memory"?
We can't do this in the "persistent UDVM" model.

 > I believe that the functionality of a "push" delimiter can already be
 > provided using the INPUT instructions.

No, because the functionality is exactly to start up the UDVM.
(Maybe you meant to say "we don't need the instantaneous UDVM model, 
because we have INPUT", but I understand that even less.)

So I still believe a "push" delimiter would be useful to indicate "yes, 
this app needs a persistent UDVM, so please start it now instead of 
waiting for the message-end delimiter".  Maybe there is another way to 
signal this -- being able to signal delimiterless UDVM-based processing 
would also allow to get rid of the byte stuffing needed otherwise.

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 12:39:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26539
	for ; Wed, 24 Apr 2002 12:39:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14788;
	Wed, 24 Apr 2002 12:34:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14757
	for ; Wed, 24 Apr 2002 12:34:14 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21921
	for ; Wed, 24 Apr 2002 12:34:09 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OGYXs29466
	for ; Wed, 24 Apr 2002 11:34:33 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Apr 2002 09:34:08 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 24 Apr 2002 11:32:54 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue sugar-3
Date: Wed, 24 Apr 2002 11:32:53 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue sugar-3
Thread-Index: AcHrdltUAmWQJvH6TEKvJj4m54+I3QAMy3fA
To: , 
Cc: , 
X-OriginalArrivalTime: 24 Apr 2002 16:32:54.0624 (UTC) FILETIME=[AF507600:01C1EBAD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA14758
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

Re the stack_location overwritten, I'll vote for treating
it as decompression failure too. It's simple and makes sense
(though we're living in a crazy world).

Then, I don't see why we need to mandate the value of 
stack_location to be >= 56. The idea of stack_location
is to allow the compressor to specify where it wants
to grow the stack. If it screws up, then it's one way
ticket to decompression failure.

BTW, what is the reason for the mysterious reserved field 
(10-15)? Same question for the gap 16-47 (i.e. any particular
reason to put the registers at area starting 48?).

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 13:21:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29485
	for ; Wed, 24 Apr 2002 13:21:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17848;
	Wed, 24 Apr 2002 13:15:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17817
	for ; Wed, 24 Apr 2002 13:15:21 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29209
	for ; Wed, 24 Apr 2002 13:15:11 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OHHrH19268
	for ; Wed, 24 Apr 2002 12:17:53 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Apr 2002 10:15:01 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 24 Apr 2002 12:15:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue cabo-11
Date: Wed, 24 Apr 2002 12:15:00 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-11
Thread-Index: AcHqG2TTQB17ZQEjTwOe+MldzfO9WABk0/rw
To: , 
Cc: , 
X-OriginalArrivalTime: 24 Apr 2002 17:15:00.0555 (UTC) FILETIME=[90E2F1B0:01C1EBB3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA17818
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> My current assumption is that this will depend on the 
> application security mechanism. If security is provided by the 
> application itself then I expect one SigComp session to map onto 
> exactly one application session (snip)

Why? According to your proposed text, states will be deleted 
(well, if the reference_count == 0) at the end of a SigComp 
session. So, the above means that the states created by one
application session cannot be used later in another application
session.

Actually, this is one reason I don't like the introduction of 
term "session" in pre-06 text. Its introduction leads to the
additions of "per-session" text everywhere, which IMO is 
implementation issue and need not be specified in SigComp.

I prefer the term "compartment" as proposed by Carsten which
captures precisely the issues here, i.e. memory management
and identifying the receiver of a feedback. More important,
its meaning is confined to space dimension and does not spill 
over to the time dimension (which again looks an implementation 
issue to me).

BR,
Zhigang



_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 15:35:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04772
	for ; Wed, 24 Apr 2002 15:35:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26463;
	Wed, 24 Apr 2002 15:32:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26426
	for ; Wed, 24 Apr 2002 15:32:32 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04676
	for ; Wed, 24 Apr 2002 15:32:28 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OJZGH07214
	for ; Wed, 24 Apr 2002 14:35:16 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Apr 2002 12:32:29 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 24 Apr 2002 14:32:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompression failure ?
Date: Wed, 24 Apr 2002 14:32:28 -0500
Message-ID: 
Thread-Topic: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompression failure ?
Thread-Index: AcHiTkGP0SDI7KUKQKCEUqKJdvcfOQJdQspw
To: , 
Cc: , 
X-OriginalArrivalTime: 24 Apr 2002 19:32:29.0269 (UTC) FILETIME=[C580D050:01C1EBC6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA26431
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

Can we allow a standalone RESET message from a decompressor
to its peer compressor indicating that it has lost the
dynamic states during a crash, and thus ask the compressor
to restart with only static states? Since security is
an obvious concern, let's assume the question is about 
an environment that you have secure channel under SigComp.

Of course, one solution is to let the application to signal 
the crash. But what if implementer does not want to change
the existing signalling (say SIP) message flow? Then it seems
that sending this signal at SigComp level will make the 
addition of SigComp much simpler and easier.

(This is actually a feedback I received from my colleague in 
3GPP even after I had explained the current thinking in IETF).

RB,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 17:34:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09959
	for ; Wed, 24 Apr 2002 17:34:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02938;
	Wed, 24 Apr 2002 17:33:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02907
	for ; Wed, 24 Apr 2002 17:33:06 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09945
	for ; Wed, 24 Apr 2002 17:33:01 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OLZjH23020
	for ; Wed, 24 Apr 2002 16:35:50 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Apr 2002 14:32:55 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 24 Apr 2002 16:31:49 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue cabo-15
Date: Wed, 24 Apr 2002 16:31:48 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue cabo-15
Thread-Index: AcHqz3JPsEgxtHFfTsyiAvUFf7lWOQBBBbDQ
To: , , 
X-OriginalArrivalTime: 24 Apr 2002 21:31:49.0596 (UTC) FILETIME=[716401C0:01C1EBD7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA02908
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> state_memory_size: 0 octets

I still believe the value should be 1024. 

- If the host is a client, 1 KB is not something too much to ask.
- If the host is a server, then 1KB per client should not be
a problem either. In practice, an administrator anyway needs to 
make provision for memory cost according to expected number of 
clients. 

> "decompression_memory_size: 2048 octets

No problem with the number itself, but has anyone checked on
the impacts of combining compressed message size and UDVM memory
size to the logic at compressor side (see below)?

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00448.html

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Wed Apr 24 18:59:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11063
	for ; Wed, 24 Apr 2002 18:59:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06800;
	Wed, 24 Apr 2002 18:53:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06769
	for ; Wed, 24 Apr 2002 18:53:51 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10955
	for ; Wed, 24 Apr 2002 18:53:42 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OMs8s24396
	for ; Wed, 24 Apr 2002 17:54:08 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Apr 2002 15:53:46 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 24 Apr 2002 17:53:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
Date: Wed, 24 Apr 2002 17:53:46 -0500
Message-ID: 
Thread-Topic: [rohc] sigcomp issue sugar-5/cabo-8
Thread-Index: AcHq1ddQgsWN2TDhTWOht02LFCHN+QBAe1oQ
To: , 
Cc: 
X-OriginalArrivalTime: 24 Apr 2002 22:53:46.0192 (UTC) FILETIME=[E3E90500:01C1EBE2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA06770
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

> > 2) deduct the size of the freed state from the state_memory size for 
> > the compressor
> 
> This step, of course, is not executed if the state isn't still being
> referenced (maybe you meant this by "stop").

Yes (see below).

> > 3) decrement the counter associated with the freed state by 1. 
> > (Note, the counter of a state is incremented whenever a compressor 
> > requests to create a state that has already been created)
> 
> Hmm, packet loss/retransmissions again.
> The counter should only be increased if the state has newly entered
> the set of state associated with this session/compartment.
> Repeated STATE-CREATE for the same session/compartment should 
> not count.

Good point. Now thinking along this line, perhaps counter is not a good
word to describe this. How about the following?

a) set(compartment-ID) = a set of states associated with this compartment

b) set(state-ID) = a set of compartment IDs that have requested to create
the state.

c) A valid request from compartment-ID cid to create state s will
trigger the following:   
    set(cid) <- set(cid) U {s}
    set(s) <- set(s) U {cid}

d) A valid request of STATE_FREE(s) from compartment-ID cid will 
trigger the following:
    set(cid) <- set(cid) - set(cid)^{s}
    set(s) <- set(s) - set(s)^{cid}

e) When set(s) is empty, the state s can be physically deleted.

Note: 'U' stands for union and '^' for intersection.

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 03:39:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28384
	for ; Thu, 25 Apr 2002 03:39:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13731;
	Thu, 25 Apr 2002 03:35:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13699
	for ; Thu, 25 Apr 2002 03:35:38 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28348
	for ; Thu, 25 Apr 2002 03:35:30 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3P7ZW0E016319
	for ; Thu, 25 Apr 2002 09:35:32 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 25 09:35:31 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 25 Apr 2002 09:24:56 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'rohc@ietf.org'" 
Date: Thu, 25 Apr 2002 09:35:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA13700
Subject: [rohc] sigcomp issue lejo-9
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

I agree with Carsten that "specification required" is a too weak
requirement for sigcomp version assignment. Assignment should
instead be based on "Standards Action". The IANA section could
then be modified to the following:


"SigComp requires a 2-octet name space, the SigComp_version, to
be assigned by the IANA. Upgraded versions of SigComp must be
backwards-compatible with version 0x0000, described in this
document. Adding additional UDVM instructions and assigning
values to the reserved UDVM memory addresses are two possible
upgrades for which this is the case.

Following the policies outlined in [RFC-2434], the IANA policy
for assigning a new value for the SigComp_version shall require
a Standards Action. Values are thus assigned only for Standards
Track RFCs approved by the IESG."


Any comments?

BR
/Lars-Erik


-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research and Experiments
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 04:50:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29474
	for ; Thu, 25 Apr 2002 04:50:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18395;
	Thu, 25 Apr 2002 04:44:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18359
	for ; Thu, 25 Apr 2002 04:44:37 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29444
	for ; Thu, 25 Apr 2002 04:44:33 -0400 (EDT)
Received: from tzi.org (nmh.informatik.uni-bremen.de [134.102.224.3])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3P8iOj05344;
	Thu, 25 Apr 2002 10:44:24 +0200 (MEST)
Message-ID: <3CC7C1E3.70300@tzi.org>
Date: Thu, 25 Apr 2002 10:44:19 +0200
From: Carsten Bormann 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Lars-Erik Jonsson (EPL)" 
CC: "'rohc@ietf.org'" 
Subject: Re: [rohc] sigcomp issue lejo-9
References: 
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit

Lars-Erik Jonsson (EPL) wrote:
> Hi all,
> 
> I agree with Carsten that "specification required" is a too weak
> requirement for sigcomp version assignment. Assignment should
> instead be based on "Standards Action". The IANA section could
> then be modified to the following:
> 
> 
> "SigComp requires a 2-octet name space, the SigComp_version, to
> be assigned by the IANA. Upgraded versions of SigComp must be
> backwards-compatible with version 0x0000, described in this
> document. Adding additional UDVM instructions and assigning
> values to the reserved UDVM memory addresses are two possible
> upgrades for which this is the case.
> 
> Following the policies outlined in [RFC-2434], the IANA policy
> for assigning a new value for the SigComp_version shall require
> a Standards Action. Values are thus assigned only for Standards
> Track RFCs approved by the IESG."
> 
> 
> Any comments?

Yes -- the other part of the issue was whether we actually need two 
bytes for the ID.
For ROHC, we decided to use two bytes in order to express two dimensions:
Different Profiles (one for RTP, one for ESP, one for TCP and so on), 
and different versions ("upgrades") of the same profile.
I don't see the first dimension for the UDVM.
So, 256 different versions should be enough for quite some time (a 
century if we standardize a new version every five months).
Since the UDVM version actually needs to be transported around, one 
additional byte may not be entirely trivial.

Another interesting item raised by your message is that of upward 
compatibility of pre-initialized VM values.  The compressor can 
currently rely on all memory cells being initialized to zero, except 
those identified in the document.  Since a compressor does not indicate 
the UDVM version it expects, UDVMs cannot pre-initialize other VM values 
without possibly causing unexpected results.
On the other hand, initializing the memory is a must for security 
reasons, and being able to rely on zeroes is good for saving superfluous 
initializations.  So maybe we want to reserve an area for extensions?
(Probably taking care not to pollute the efficiently addressable space 
too much further.)

Gruesse, Carsten


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 06:06:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00305
	for ; Thu, 25 Apr 2002 06:06:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22401;
	Thu, 25 Apr 2002 06:04:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22361
	for ; Thu, 25 Apr 2002 06:04:54 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00270;
	Thu, 25 Apr 2002 06:04:45 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3PA4i0E013070;
	Thu, 25 Apr 2002 12:04:48 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g3PA4ikw015077;
	Thu, 25 Apr 2002 13:04:44 +0300 (EET DST)
Message-ID: <3CC7D4B6.4480B8AA@lmf.ericsson.se>
Date: Thu, 25 Apr 2002 13:04:38 +0300
From: Gonzalo Camarillo 
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip , rohc 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [rohc] SigComp and SIP
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

I have put together a draft about how to use SigComp and SIP.

Until it appears in the archives, you can fetch it from:
http://www.cs.columbia.edu/~gonzalo/draft-camarillo-sip-compression-00.txt

Note that this draft does *not* describe a DNS based approach.

As usual, feedback is welcome.

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 06:44:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00743
	for ; Thu, 25 Apr 2002 06:44:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23947;
	Thu, 25 Apr 2002 06:35:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23912
	for ; Thu, 25 Apr 2002 06:35:11 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00614
	for ; Thu, 25 Apr 2002 06:35:08 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3PAZ90E027295
	for ; Thu, 25 Apr 2002 12:35:09 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 25 12:32:12 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTWN7A>; Thu, 25 Apr 2002 12:35:04 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'Carsten Bormann'" 
Cc: "'rohc@ietf.org'" 
Subject: RE: [rohc] sigcomp issue lejo-9
Date: Thu, 25 Apr 2002 12:34:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

> CABO: So, 256 different versions should be enough for quite some time
> (a century if we standardize a new version every five months).
> Since the UDVM version actually needs to be transported around, one 
> additional byte may not be entirely trivial.

You're right, I just forgot to change that (too simple modification to remember). The text should then be:

"SigComp requires a 1-octet name space, the SigComp_version,
to be created by the IANA. Upgraded versions of SigComp must
be backwards-compatible with version 0x00, described in this
document. Adding additional UDVM instructions and assigning
values to the reserved UDVM memory addresses are two possible
upgrades for which this is the case.

Following the policies outlined in [RFC-2434], the IANA policy
for assigning a new value for the SigComp_version shall require
a Standards Action. Values are thus assigned only for Standards
Track RFCs approved by the IESG."

/L-E 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 07:00:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00890
	for ; Thu, 25 Apr 2002 07:00:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24400;
	Thu, 25 Apr 2002 06:50:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24373
	for ; Thu, 25 Apr 2002 06:50:36 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00817
	for ; Thu, 25 Apr 2002 06:50:33 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3PAoY0E005632
	for ; Thu, 25 Apr 2002 12:50:34 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 25 12:47:41 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTW3VM>; Thu, 25 Apr 2002 12:50:33 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'Carsten Bormann'" 
Cc: "'rohc@ietf.org'" 
Subject: NEW: sigcomp issue cabo-16  (was: RE: [rohc] sigcomp issue lejo-9
	)
Date: Thu, 25 Apr 2002 12:50:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Since this is a different issue than what lejo-9 addressed,
we should thus track it separately. I've taken the liberty
to call it cabo-16, since it was brought up by Carsten.

Please express your opinions and suggest actions to this
new issue, we should not let it introduce additional delay.

Cheers,
/L-E


> Another interesting item raised by your message is that of upward 
> compatibility of pre-initialized VM values.  The compressor can 
> currently rely on all memory cells being initialized to zero, except 
> those identified in the document.  Since a compressor does 
> not indicate 
> the UDVM version it expects, UDVMs cannot pre-initialize 
> other VM values 
> without possibly causing unexpected results.
> On the other hand, initializing the memory is a must for security 
> reasons, and being able to rely on zeroes is good for saving 
> superfluous 
> initializations.  So maybe we want to reserve an area for extensions?
> (Probably taking care not to pollute the efficiently 
> addressable space 
> too much further.)
> 
> Gruesse, Carsten
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 08:10:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02318
	for ; Thu, 25 Apr 2002 08:10:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00585;
	Thu, 25 Apr 2002 08:07:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00551
	for ; Thu, 25 Apr 2002 08:07:47 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02122
	for ; Thu, 25 Apr 2002 08:07:40 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4XZQ>; Thu, 25 Apr 2002 13:03:28 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFFD@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'Carsten Bormann'" 
Cc: "'cabo@Informatik.Uni-Bremen.DE'" ,
        rohc@ietf.org
Subject: RE: [rohc] sigcomp issue sugar-3
Date: Thu, 25 Apr 2002 13:03:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

> > Assuming that we want to store the stack in low memory, I'd be marginally
> > happier if we call a decompression failure when the stack overwrites its
> > own stack_location. However, any solution is fine provided that it isn't
> > along the lines of "crash horribly and corrupt the memory for the entire
> > endpoint"!
> 
> Based on Mark's message today, I propose the new text I just checked in, 
> which makes the behavior in this case unpredictable (and encourages 
> DECOMPRESSION-FAILURE in a "checking" implementation).  It also defines 
> the stack in (I hope) a slightly more rigorous manner.
> 
> Comments?

Carsten,

Allowing the UDVM to behave unpredictably is dangerous from a security
perspective, because it isn't clear which implementation options pose an
unacceptable security risk.

For example, in the interests of performance it might seem sensible to
leave the initial contents of the UDVM memory undefined. However, this
would open a major security hole if an implementer chose to just reuse
the UDVM memory from the last message (possibly containing important
data that is supposed to be secure against malicious access).

Whilst I'm not particularly concerned with the exact way that stack
manipulation instructions cope with overwriting the stack_location, I
believe strongly that we shouldn't allow a particular behaviour unless
it is well-defined in the draft and has been checked for possible
security implications.

In this particular case, it turns out that the stack is written to at most
twice by any single stack manipulation instruction. Therefore it appears
that there are exactly three sensible implementation choices that do not
pose extra security risks compared with SigComp-05:

1.  When the instruction writes to the stack, if stack_location or
    stack_fill are overwritten then decompression failure is called.

2.  When the instruction first writes to the stack, if stack_location or
    stack_fill are overwritten then the old values must still be used
    when writing to the stack for a second time.

3.  When the instruction first writes to the stack, if stack_location or
    stack_fill are overwritten then the new values are used when writing
    to the stack for a second time.

Choice 1 is the simplest to describe (if not to implement). However, if
performance is a goal then the best choice appears to be 3 as it avoids
the need to protect stack_location or stack_fill at all. We can just read
the values directly from the UDVM memory when they are needed.

It would also be OK to describe all three options in the draft and let
implementers choose for themselves (although in this case it doesn't
seem to buy us anything over just making choice 3 mandatory).

Regards,

Richard

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 08:54:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04068
	for ; Thu, 25 Apr 2002 08:54:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03880;
	Thu, 25 Apr 2002 08:49:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03837
	for ; Thu, 25 Apr 2002 08:49:41 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03909
	for ; Thu, 25 Apr 2002 08:49:38 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R4X7S>; Thu, 25 Apr 2002 13:42:02 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0EFFE@rsys002a.roke.co.uk>
From: "Price, Richard" 
To: "'zhigang.c.liu@nokia.com'" , cabo@tzi.org
Cc: Hans.Hannu@epl.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompr
	ession failure ?
Date: Thu, 25 Apr 2002 13:41:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

RESET messages are possible within the current SigComp-06 draft:
just send a message that sets the state_memory_size to 0 and the
receiver will know that all of the dynamic states have been lost.

A RESET message will normally need to be sent piggybacked onto an
application message, otherwise the receiving endpoint will simply
discard it. However if security is provided by the lower layer
then standalone RESET messages are currently allowed by SigComp
(although the issue of standalone messages is still being discussed
as part of cabo-11).

Regards,

Richard

> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: Wednesday, April 24, 2002 8:32 PM
> To: cabo@tzi.org; Price, Richard
> Cc: Hans.Hannu@epl.ericsson.se; rohc@ietf.org
> Subject: RE: [rohc] RE: sigcomp issue zliu-3: cannot recovery from
> decompression failure ?
> 
> 
> Hi,
> 
> Can we allow a standalone RESET message from a decompressor
> to its peer compressor indicating that it has lost the
> dynamic states during a crash, and thus ask the compressor
> to restart with only static states? Since security is
> an obvious concern, let's assume the question is about 
> an environment that you have secure channel under SigComp.
> 
> Of course, one solution is to let the application to signal 
> the crash. But what if implementer does not want to change
> the existing signalling (say SIP) message flow? Then it seems
> that sending this signal at SigComp level will make the 
> addition of SigComp much simpler and easier.
> 
> (This is actually a feedback I received from my colleague in 
> 3GPP even after I had explained the current thinking in IETF).
> 
> RB,
> Zhigang
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 09:56:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06259
	for ; Thu, 25 Apr 2002 09:56:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07940;
	Thu, 25 Apr 2002 09:48:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07909
	for ; Thu, 25 Apr 2002 09:48:03 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05985
	for ; Thu, 25 Apr 2002 09:47:59 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3PDm0s7013344
	for ; Thu, 25 Apr 2002 15:48:00 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 25 15:45:04 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTWZNY>; Thu, 25 Apr 2002 15:47:56 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'rohc@ietf.org'" 
Date: Thu, 25 Apr 2002 15:46:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] Closing sigcomp issues - Instalment 2
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Dear all,

After closing most SigComp issues, as listed in Instalment 1, it is time
to address the ones still open. I will not focus on the technical content
of these open issues, but mainly on the status, as it looks from the 
discussions on the list.

The issues still open are:
  lejo-7
  lejo-8
  lejo-9
  lejo-10*
  rp-1
  rp-8
  cabo-11
  cabo-8
  cabo-6*
  cabo-15*
  cabo-16
  sugar-3
  sugar-6*


From what I have seen on the list, it should now be possible to close
some of these issues, since solutions have been proposed without
objections, or with rough consensus to go on with the proposed solution.
These issues are (also marked above):

lejo-10:
  
  Issue has been discussed and finally summarized by Hans in:
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00450.html
  There have been no objections to this summary.

  Resolution proposal: Clarify sender behavior if S-bit is switched back
                       to zero. The text of Section 9.4.7 should be updated
                       based on the following text:
  
  "The sending endpoint is welcome to change its mind and switch the S-bit
  back to 0 in a later message. However, the receiving endpoint is under
  no obligation to use the original state_memory_size for the session; it
  may choose to allocate less memory to the session or possibly none at all.

  Note: The format of Figure 13 is 
  only for *local* presentation of parameters on the interface between 
  UDVM and state handler, NOT a format for transmission between two 
  endpoints."


cabo-6:

  Issue has been discussed on the list, and Richard has explained the
  purpose of the current proposal in the draft:
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00443.html
  Answer - "Feature", stick to what is in -05a
  There have been no objections to this proposal.

  Resolution proposal: Resolution proposed in current editors' working
                       document. 


cab0-15:
 
  Issue has been discussed on the list, and there seems to be rough
  consensus to stick to what is currently in the draft:
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00461.html

  Resolution proposal: Resolution proposed in current editors' working
                       document. 

  "decompression_memory_size: 2048 octets
  state_memory_size: 0 octets
  cycles_per_bit: 16
  SigComp_version: 0
  locally available state: none"


sugar-6:
 
  Issue has been discussed on the list, and there seems to be rough
  consensus that this functionality can already be provided, based
  on current editors' document.

  Resolution proposal: No special action needed. Resolution provided
                       by current editors' working document. 



--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Thu Apr 25 10:18:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06865
	for ; Thu, 25 Apr 2002 10:18:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09469;
	Thu, 25 Apr 2002 10:05:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09399
	for ; Thu, 25 Apr 2002 10:05:33 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06552;
	Thu, 25 Apr 2002 10:05:29 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.76])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3PE5lLC005598;
	Thu, 25 Apr 2002 10:05:47 -0400 (EDT)
Message-ID: <3CC80CEA.7341993D@dynamicsoft.com>
Date: Thu, 25 Apr 2002 10:04:26 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo 
CC: sip , rohc 
Subject: Re: [rohc] SigComp and SIP
References: <3CC7D4B6.4480B8AA@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit

Gonzalo,

I think this is definitely a step in the right direction. I'll note that
this is yet another thing that wouldn't work without loose routing :)

A few comments:

* Section 3 leaves out an important means for obtaining the URI -
configuration. Ultimately, we want to move towards configuration of
outbound proxies through URIs, NOT IP addresses. One reason is that we
can support supplemantal information, just like this, as part of the
URI. 

* I think a client MUST NOT send a sigcomp request to a server if it
doesn't know whether it supports compression. Section 3 provides cases
in which you can sort of guess whether it does. I don't like that. The
guesses are just that - guesses, and may be wrong. Indeed, the
heuristics are somewhat ill defined. For example:

>  o In a previous transaction, the client obtained a URI for the
>           same server with the parameter comp=sigcomp (e.g., a Contact
>           header field in a 2xx response for a previous OPTIONS request
>           or an entry in the route set of a previous dialog).

How do I know that the OPTIONS request this time was routed to the same
element that got it last time? Indeed, if, last time, the contact URI in
the 2xx to OPTIONS had a comp param, and this time, it doesn't, isn't
this a good sign that it has NOT been routed to the same UA?


* I think its worth noting a few things about this approach. First, a
proxy that gets a request uncompressed, and wants to get it compressed
in subsequent requests, can return a 301 with a contact header that has
the comp parameter. This will result in a caching of the binding in the
client that sent the request. Secondly, a SIP element that implements
this will need to be prepared to receive compressed or uncompressed
messages on the same port, and thus will need to look at the cookie in
the topmost bits to demux.



> A response is sent to the host in the sent-by parameter of the Via
>    header field. If the topmost Via header field contains the parameter
>    comp=sigcomp, the response SHOULD be compressed. Otherwise, the
>    response SHOULD NOT be compressed.

I would say MUST NOT be compressed. The criteria is - will things work
if you violate this? If I send a compressed response to something which
doesn't support it, the response is discarded. The result is total
failure of the transaction. There is no recovrey. So, it should be MUST
NOT.

>  A proxy performing Record-Route inspects the Record-Route and the
>    Contact header fields in the response. It looks for the URI of the
>    next upstream (closer to the user agent client) hop in the route set.
>    If this URI contains the parameter comp=sigcomp, the proxy SHOULD add
>    comp=sigcomp to its entry in the Record-Route header field.

Why? If the upstream element doesn't support this extension, the sigcomp
parameter is ignored, and the message is sent uncompressed. Thats what
you want. The decision about whether to insert a URI with the comp
parameter should be entirely a local one.

* section 7 - i think these considerations are addressed by sigcomp
itself. You should really discuss whether the proposed mechanism
introduces additional issues.


Thanks,
Jonathan R.


Gonzalo Camarillo wrote:
> 
> Folks,
> 
> I have put together a draft about how to use SigComp and SIP.
> 
> Until it appears in the archives, you can fetch it from:
> http://www.cs.columbia.edu/~gonzalo/draft-camarillo-sip-compression-00.t
> xt
> 
> Note that this draft does *not* describe a DNS based approach.
> 
> As usual, feedback is welcome.
> 
> Regards,
> 
> Gonzalo
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Fri Apr 26 05:37:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28182
	for ; Fri, 26 Apr 2002 05:37:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27304;
	Fri, 26 Apr 2002 05:31:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27267
	for ; Fri, 26 Apr 2002 05:31:22 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28106
	for ; Fri, 26 Apr 2002 05:31:17 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3Q9VK0E016240
	for ; Fri, 26 Apr 2002 11:31:20 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 26 11:32:17 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 26 Apr 2002 11:19:40 +0200
Message-ID: 
From: "Lars-Erik Jonsson (EPL)" 
To: "'rohc@ietf.org'" 
Subject: RE: [rohc] Closing sigcomp issues - Instalment 2 [UPDATED]
Date: Fri, 26 Apr 2002 11:30:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Dear all,
 
After closing most SigComp issues, as listed in Instalment 1, 
it is time to address the ones still open. I will not focus
on the technical content of these open issues, but mainly on
the status, as it looks from the discussions on the list.
Please ignore the previous posting of Instalment 2, since 
it was not complete. The issues discussed in this updated
version are those that will be considered as part of 
Instalment 2. The rest will be handled in a final Instalment 3.

The issues still open are:
  lejo-7
  lejo-8
  lejo-9*
  lejo-10*
  rp-1
  rp-8
  cabo-11
  cabo-8
  cabo-6*
  cabo-15*
  cabo-16
  sugar-3*
  sugar-6*
 
 
From what I have seen on the list, it should now be possible
to close some of these issues, since solutions have been
proposed without objections, or with rough consensus to go on
with the  proposed solution. These issues are (also marked 
with a "*" above):


lejo-9:

  The IANA section has been rewritten, with minor adjustments,
  based on discussions on the list.

  Resolution proposal: Replace current text with the following:

  "SigComp requires a 1-octet name space, the SigComp_version,
  to be created by the IANA. Upgraded versions of SigComp must
  be backwards-compatible with version 0x00, described in this
  document. Adding additional UDVM instructions and assigning
  values to the reserved UDVM memory addresses are two possible
  upgrades for which this is the case.

  Following the policies outlined in [RFC-2434], the IANA policy
  for assigning a new value for the SigComp_version shall require
  a Standards Action. Values are thus assigned only for Standards
  Track RFCs approved by the IESG."

 
lejo-10:
  
  Issue has been discussed and finally summarized by Hans in:
  
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00450.html
  There have been no objections to this summary.
 
  Resolution proposal: Clarify sender behavior if S-bit is
                       switched back to zero. The text of
                       Section 9.4.7 should be updated
                       based on the following text:
   
  "The sending endpoint is welcome to change its mind and switch
  the S-bit back to 0 in a later message. However, the receiving 
  endpoint is under no obligation to use the original
  state_memory_size for the session; it may choose to allocate
  less memory to the session or possibly none at all.
 
  Note: The format of Figure 13 is only for *local* presentation
  of parameters on the interface between UDVM and state handler,
  NOT a format for transmission between two endpoints."
 
 
cabo-6:
 
  Issue has been discussed on the list, and Richard has explained
  the purpose of the current proposal in the draft:
   
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00443.html
  Answer - "Feature", stick to what is in -05a
  There have been no objections to this proposal.

  Resolution proposal: Resolution proposed in current editors'
                       working document. 


cab0-15:
 
  Issue has been discussed on the list, and there seems to be
  rough consensus to stick to what is currently in the draft:
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00461.html

  Resolution proposal: Resolution proposed in current editors'
                       working document. 

  "decompression_memory_size: 2048 octets
  state_memory_size: 0 octets
  cycles_per_bit: 16
  SigComp_version: 0
  locally available state: none"


sugar-3:

  Issue has been discussed on the list, and a proposed action
  been provided by Carsten.

  Resolution proposal: Resolution proposed in current editor's
                       working document.


sugar-6:
 
  Issue has been discussed on the list, and there seems to be
  rough consensus that this functionality can already be
  provided, based on current editors' document.

  Resolution proposal: No action needed. Resolution provided
                       in current editors' working document. 



--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 29 09:56:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08489
	for ; Mon, 29 Apr 2002 09:56:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21900;
	Mon, 29 Apr 2002 09:47:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21868
	for ; Mon, 29 Apr 2002 09:47:44 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07654
	for ; Mon, 29 Apr 2002 09:47:35 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3TDlb0E003390
	for ; Mon, 29 Apr 2002 15:47:37 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 29 15:46:38 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBT5A78>; Mon, 29 Apr 2002 15:46:38 +0200
Message-ID: 
From: "Hans Hannu (EPL)" 
To: "'rohc@ietf.org'" 
Date: Mon, 29 Apr 2002 15:47:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] SigComp-extended
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org

Hi,

FYI, the authors are working on updating the SigComp-extended draft according to what was said at the Minneapolis meeting.

The changes are made to match the current working SigComp document, e.g.
the changes to the feedback mechanism of SigComp has affected the 
acknowledgement scheme in SigComp-extended as follows: (The ones of you 
who have taken a look at the slides from Minneapolis may recognize Figure
 3 below, I think I showed that one 4 times in the presentation ;-))

"5.1.1.1. Remote compressor initiated acknowledgements

   This is the case when e.g. compressor 1 has uploaded UDVM code to
   decompressor 2. The UDVM code will use the requested and returned
   feedback fields in the announcement information to obtain knowledge
   about established states at endpoint 2.

   Consider Figure 3. An event flow for successful use of remote
   compressor initiated acknowledgements can be as follows:

   (1): Compressor 1 saves e.g. state(A).
   (2): The UDVM code to initiate a state save for state(A) is either
        carried in the compressed message, or already in place at
        decompressor 2.
   (3): As compressor 1 is the initiator of this acknowledgement it can
        use an arbitrary identifier to be returned to indicate that
        state(A) has been established. The identifier needs to consist
        of enough bits to avoid acknowledgement of wrong state. To avoid
        padding of the feedback items and for simplicity a minimum of 1
        octet should be used for the identifier.
        The identifier is placed at the location of the
        requested_feedback_item [SigComp]. The END-MESSAGE instruction
        is used to indicate the location of the requested_feedback_item
        to the state handler.
   (4): The requested feedback data is now called returned feedback data
        as it is placed into the SigComp message at compressor 2.
   (5): The returned feedback item are carried in the SigComp message
        according to Figure 4: see Section 6.1 and [SIGCOMP].
   (6): The returned feedback item are handled according to: Section 7
        of [SIGCOMP]

      +--------------+           (2)              +--------------+
      | Compressor 1 |--------------------------->|Decompressor 2|
      +------^-------+                            +-------^------+
             |    (1)                              (3)    |
         +---v---+                                    +---v---+
         |State  |                                    |State  |
         |handler|                                    |handler|
         +---^---+                                    +---^---+
             |    (6)                              (4)    |
      +------v-------+           (5)              +-------v------+
      |Decompressor 1|<---------------------------| Compressor 2 |
      +--------------+                            +--------------+
                    Figure 3. Simplified SigComp endpoints"

We are currently doing some clarifications to the shared compression 
section, such as specifying the parameters of the shared state. As soon 
as SigComp-06 ready for submission, also SigComp-Extended-03 will be 
submitted.

BR
/Hans H
 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Mon Apr 29 22:29:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26686
	for ; Mon, 29 Apr 2002 22:29:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11432;
	Mon, 29 Apr 2002 22:21:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11401
	for ; Mon, 29 Apr 2002 22:21:24 -0400 (EDT)
Received: from mail-jpn.microsoft.com (mail-jpn.microsoft.com [207.46.71.29])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26623
	for ; Mon, 29 Apr 2002 22:21:19 -0400 (EDT)
Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 30 Apr 2002 11:20:51 +0900
Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 11:20:51 +0900
Received: from bjs-msg-01.fareast.corp.microsoft.com ([157.60.72.120]) by jpn-imc-01.fareast.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 30 Apr 2002 11:20:51 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [rohc] proposals for generic notation of compressed header
Date: Tue, 30 Apr 2002 10:20:50 +0800
Message-ID: 
Thread-Topic: [rohc] proposals for generic notation of compressed header
Thread-Index: AcHg5oyTzcB5URRwQZKz12n+siTULwDfumVwAuAtFgA=
From: "Qian Zhang" 
To: "West, Mark (ITN)" 
Cc: 
X-OriginalArrivalTime: 30 Apr 2002 02:20:51.0435 (UTC) FILETIME=[A5FF63B0:01C1EFED]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA11402
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Hi Mark,
 
As we promised in the last email, we now give the generic notation for
the structure of header and identify the fields in the uncompressed
header.

Regards,

Qian & Hongbin

> Yeah, agree. We really need a way to present the structure of the
header
> and identify the fields in the uncompressed header before go detail
> about how to encode it.
> The formal definition of header in our previous letter may be a good
> candidate to present the structure of the header.
> tcp-header := source-port
>               destination-port
>               ......
> source-port      := bits(16)
> destination-port   := bits(16)
> ......
> 
> Note that we may need to add some other notation to present the '|'
and
> '*'. We are now working on this.
> 

We introduce the following notations to express the uncompressed header.

a. BITS
ABNF notation: "BITS("  ")"
The length in bits of the record is .

b. VALUE
ABNF notation: "VALUE("  ","  ")"
The value of record is  and the length in bits of the record is
.

c. PADDING-F
ABNF notation: "F-PADDING("  ","  ","
 ","  ")"
The record specified by  is aligned on  bits,
the padded value is  which length in bits is
. The padded value is added at the front of the
record's value.

d. PADDING-T
ABNF notation: "T-PADDING("  ","  ","
 ","  ")"

The record specified by  is aligned on  bits,
the padded value is  which length in bits is
. The padded value is added at the tail of the
record's value.

e. LIST-N
ABNF notation: "LIST-N("  ","  "," *(","
) ")"
The record is composed of a list of records (we will refer them as
sub-record) in any order, and each sub-record of them may occurs 0 or
more times. The  specifies the number of sub-records in the
list. The rest s are the possible sub-records of the list.
Furthermore, the second  specify a default record-name if a
sub-record cannot match other s.

f. LIST-0
ABNF notation: "LIST-0("  ","  "," *(","
) ")"
The record is composed of a list of records (we will refer them as
sub-record) in any order, and each sub-record of them may occurs 0 or
more times. The first  specifies the sub-record which is
used as the indicator of the ending of list. The rest s are
the possible sub-records of the list. Furthermore, the second
record-name specify a default  if a sub-record cannot match
other s (including the first .)

g. LIST-L
ABNF notation: "LIST-L("  ","  "," *(","
) ")"
The record is composed of a list of records (we will refer them as
sub-record) in any order, and each sub-record of them may occurs 0 or
more times. The  specifies the maximum length in octets of the
record. The following s are the possible sub-records of the
list. Furthermore, the first  specify a default record-name
if a record cannot match other s.

The following is the notation of uncompressed TCP header:

uncompressed-tcp-header := tcp-source-port
				tcp-destination-port
				tcp-sequence-number
				tcp-acknowledgment-number
				tcp-data-offset
				tcp-reversed
				tcp-ecn
				tcp-control-bits
				tcp-window
				tcp-checksum
				tcp-urgent-pointer
				PADDING-T(tcp-options, 32, 0, 8)

tcp-source-port       := BITS(16)
tcp-destination-port  := BITS(16)

tcp-sequence-number	   := BITS(32)
tcp-acknowledgment-number  := BITS(32)

tcp-data-offset	:= BITS(4)

tcp-reversed := BITS(4)

tcp-ecn :=	tcp-cwr
		tcp-ece
tcp-cwr := BITS(1)
tcp-ece := BITS(1)

tcp-control-bits := tcp-urg
			  tcp-ack
			  tcp-psh
			  tcp-rst
			  tcp-syn
			  tcp-fin
tcp-urg	:= BITS(1)
tcp-ack	:= BITS(1)
tcp-psh	:= BITS(1)
tcp-rst	:= BITS(1)
tcp-syn	:= BITS(1)
tcp-fin	:= BITS(1)

tcp-window	:= BITS(16)
tcp-checksum := BITS(16)
tcp-urgent-pointer	:= BITS(16)

tcp-options	:= LIST-0(tcp-opt-end, tcp-opt-generic, tcp-opt-nop,
tcp-opt-mss, tcp-opt-wscale, tcp-opt-sack-permitted, tcp-opt-sack,
tcp-opt-timestamp)

tcp-opt-generic := tcp-opt-type
			 tcp-opt-len
			 LIST-N(tcp-opt-len - 2, tcp-opt-octet)
tcp-opt-len	:=	BITS(8)
tcp-opt-octet :=	BITS(8)

tcp-opt-end	:=	VALUE(0, 8)
tcp-opt-nop	:=	VALUE(1, 8)

tcp-opt-mss	:=	VALUE(2, 8)
			VALUE(4, 8)
			BITS(16)
tcp-opt-wscale :=	VALUE(3, 8)
			VALUE(3, 8)
			BITS(8)

tcp-opt-sack-permitted := VALUE(4, 8)
				  VALUE(2)
tcp-opt-sack :=	VALUE(5, 8)
			tcp-opt-sack-len-of-blocks
			tcp-opt-sack-blocks
tcp-opt-sack-len-of-blocks := BITS(8)
tcp-opt-sack-blocks := LIST-N((tcp-opt-sack-len-of-blocks-2)/8,
tcp-opt-sack-block)
tcp-opt-sack-block :=	tcp-opt-sack-block-left
				tcp-opt-sack-block-right
tcp-opt-sack-block-left  :=	BITS(32)
tcp-opt-sack-block-right :=	BITS(32)

tcp-opt-timestamp := VALUE(8, 8)
                     VALUE(10, 8)
                     tcp-opt-timestamp-tsval
                     tcp-opt-timestamp-tsecho
tcp-opt-timestamp-tsval  :=	BITS(32)
tcp-opt-timestamp-tsecho :=	BITS(32)


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 30 00:29:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29667
	for ; Tue, 30 Apr 2002 00:29:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17103;
	Tue, 30 Apr 2002 00:28:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17060
	for ; Tue, 30 Apr 2002 00:28:01 -0400 (EDT)
Received: from mail-jpn.microsoft.com (mail-jpn.microsoft.com [207.46.71.29])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29656
	for ; Tue, 30 Apr 2002 00:27:58 -0400 (EDT)
Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 30 Apr 2002 13:27:28 +0900
Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 13:27:28 +0900
Received: from bjs-msg-01.fareast.corp.microsoft.com ([157.60.72.120]) by jpn-imc-01.fareast.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 30 Apr 2002 13:27:28 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 30 Apr 2002 12:27:27 +0800
Message-ID: 
Thread-Topic: ROHC-TCP issue: U/B mode, mode transition, and MSN
Thread-Index: AcHv/1WlEXjLZqikT/u7qN7n9IhzaQ==
From: "Qian Zhang" 
To: 
X-OriginalArrivalTime: 30 Apr 2002 04:27:28.0826 (UTC) FILETIME=[566541A0:01C1EFFF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA17061
Subject: [rohc] ROHC-TCP issue: U/B mode, mode transition, and MSN
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Dear ROHC-TCPers,
 
We are working on updating the ROHC-TCP draft according to what was discussed at the Minneapolis meeting. 
We would like to discuss the following issues in separate email thread.
1. U/B mode, mode transition, and MSN issues
2. Context replication/updating issue, especially in U-mode

In this email, we will only focus on the first issue.

Regards,

Qian & Hongbin

-------------Mode related Issue-------------------------------------------
1. U/B mode, mode transition, and MSN issues

In ROHC-TCP, the B mode and U mode is like the O mode and U mode in ROHC-RTP, respectively. The difference between B and U modes is very subtle. In B mode, the decompressor needs send back ACK to the compressor occasionally. In ACKs, we need a field or combination of several fields to uniquely identify the packet received or not. TO achieve it, the current ROHC-TCP draft use different packet formats for U and B modes and support MSN in B mode. As a result, the transition from B mode to U mode will need 4-way handshakes to synchronize the compressor and the decompressor.

Compared to the complexity introduced by 4-way handshakes, uniform packet format is more preferred. However, there comes the issue which fields can be served as a unique identifier for the packet. As we had discussed before, in RTP, each packet is uniquely identified by a SN (Sequence Number) field. However, unlike RTP, TCP don't have such a field. The SEQ or ACK field only can not identify a packet. For example, in a client/server scenario, the packets on the path from client to server only see ACK changed with SEQ unchanged. Even the combination of SEQ and ACK can not complete solve the problem. Consider the case, when a packet gets lost, the TCP receiver sends back duplicate ACK without data. The SEQ and ACK remain constant at least for 3~4 packets. Moreover, SEQ (or ACK) counts octets instead of packets and will require more space to store it even in a compressed format.

The following is our proposal that trying to solve this issue. 
Instead of using different packet formats in U and B modes, we introduce a more complex FEEDBACK format. Some TCP/IP fields are put into the FEEDBACK format to identify the packet that needs to be acknowledged. In this way, same format for data packet is supported in both B and U modes. MSN is not needed in the uncompressed or compressed data packet.
The FEEDBACK formats are different between IPv4 and IPv6 since IP-ID is only available in IPv4. For IPv4, we use IP-ID as the unique identifier of the packet. For IPv6, we use SEQ, ACK or SEQ+ACK as the identifier of the packet. 

The procedure of mode-transitions between U-mode and B-mode are a little different from the one in ROHC-RTP.

Transition from U-mode to B-mode

When there is feedback channel available, the decompressor may at any moment decide to initiate transition from U-mode to B-mode. Any feedback packet carrying a CRC can be used with the mode parameter set to B. The decompressor can then directly start working in B-mode. The compressor transits from U-mode to B-mode as soon as it receive any feedback packet that has the mode parameter set to B and that passes the CRC check. The transition procedure is described below:

U-mode to B-mode

           Compressor                       Decompressor
             ---------------------------------------------
               |        ACK(B)/NACK(B)     +-<-<-|     D_MODE = B
C_MODE = B     |       +-<-<-<-<-<-<-<-<-<-+     |
               |-<-<-<-+                         |


Transition from B-mode to U-mode

The decompressor can force a transition back to U-mode if it desires to do so. Any feedback packet carrying a CRC can be used with the mode parameter set to U. The decompressor can then directly start working in U-mode. The compressor transits from B-mode to U-mode:
1) as soon as it receive any feedback packet that has the mode parameter set to U and passes the CRC check, or 
2) for an enough long time period (TIMEOUT), it hasn't received any feedback with the mode parameter set to B. 
The detailed procedure is described below:

B-mode to U-mode

	  Compressor                       Decompressor
          ---------------------------------------------
	       |        ACK(U)/NACK(U)     +-<-<-|     D_MODE = U
C_MODE = U   |       +-<-<-<-<-<-<-<-<-<-+     |
             |-<-<-<-+                         |


The FEEDBACK format is listed as follows:

- IPv4
For IPv4, the feedback format is very similar to ROHC-RTP, we just replace the SN in ROHC-RTP with IP-ID. The format is listed as follows:

FEEDBACK-1

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|             IP-ID             |
+---+---+---+---+---+---+---+---+

FEEDBACK-2

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|AckType| Mode  |     IP-ID     |
+---+---+---+---+---+---+---+---+
|             IP-ID             |
+---+---+---+---+---+---+---+---+
/       Feedback options        /
+---+---+---+---+---+---+---+---+


- IPv6
For IPv6, we only use FEEDBACK-2, the format is as follows:

FEEDBACK-2

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|AckType| Mode  | 0 | 0 | S | A |
+---+---+---+---+---+---+---+---+
/              SEQ              / if S = 1
 ... ... ... ... ... ... ... ... 
/              ACK              / if A = 1
+---+---+---+---+---+---+---+---+
/       Feedback options        /
+---+---+---+---+---+---+---+---+

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 30 04:13:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10456
	for ; Tue, 30 Apr 2002 04:12:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05569;
	Tue, 30 Apr 2002 04:07:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05536
	for ; Tue, 30 Apr 2002 04:07:15 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10356
	for ; Tue, 30 Apr 2002 04:07:12 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R477G>; Tue, 30 Apr 2002 09:06:09 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED418036DD97B@rsys002a.roke.co.uk>
From: "McCann, Stephen" 
To: rohc@ietf.org
Date: Tue, 30 Apr 2002 09:06:07 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: [rohc] Invitation to EPIC-lite Interoperability Trails
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hello to you all,
    now that we have all warmed up after "Artic ROHC", I'd like to
invite you all to the first EPIC-lite interoperability trails to be
held at Roke Manor Research Ltd, in England, during the week 
20th May - 24th May 2002.

Our intention is to initially trial TCP and possibly SCTP.

We intend to base the trails on the following I-D :
http://www.ietf.org/internet-drafts/draft-ietf-rohc-epic-lite-01.txt

Profile information will be discussed between participants.

Please reply to me by Friday 10th May 14:00 UT, if you are interested 
in joining us and I will share more information about 
logistics with you.

Kind regards

Stephen McCann 
Roke Manor Research Ltd (A Siemens Company) 
Southampton 
UK

http://www.roke.co.uk/networks/Epic/epic.html
 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 30 04:13:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10469
	for ; Tue, 30 Apr 2002 04:13:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05616;
	Tue, 30 Apr 2002 04:07:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05580
	for ; Tue, 30 Apr 2002 04:07:25 -0400 (EDT)
Received: from mail-jpn.microsoft.com (mail-jpn.microsoft.com [207.46.71.29])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10359
	for ; Tue, 30 Apr 2002 04:07:22 -0400 (EDT)
Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 30 Apr 2002 17:06:54 +0900
Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 17:06:54 +0900
Received: from bjs-msg-01.fareast.corp.microsoft.com ([157.60.72.120]) by jpn-imc-01.fareast.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 30 Apr 2002 17:06:54 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] ROHC-TCP issue: context updating in U-mode
Date: Tue, 30 Apr 2002 16:06:52 +0800
Message-ID: 
Thread-Topic: [rohc] ROHC-TCP issue: context updating in U-mode
Thread-Index: AcHv/1WlEXjLZqikT/u7qN7n9IhzaQAHGtMg
From: "Hongbin Liao (Intl Staffing)" 
To: 
X-OriginalArrivalTime: 30 Apr 2002 08:06:54.0063 (UTC) FILETIME=[FD7CFFF0:01C1F01D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA05582
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

Dear ROHC-TCPers
	In this mail, the second, context updating issues in U-mode.

Hongbin & Qian Zhang
04/30/2002


Context updating issues, especially in U-mode

Content updating can be considered as the mechanism which establishes a context based on another valid context already created (we will refer this context as base context.) This mechanism will reduce the overhead of context building significantly, especially for short-lived TCP connections. However, in U-mode,  the compressor knows which one of existing contexts is valid without the feedback from the decompressor. If the context being selected as the base context is invalid, the context newly being created is also invalid. This issue can be solved by giving a general principle on how to select the base context. This principle is listed as follows:
	Only context in FO/SO states should be selected as the base.

When a context is being created, the compressor will select a valid state as the base and send a CONTEXT-UPDATE packet instead of IR/IR-DYN packet. Each time the compressor send a CONTEXT-UPDATE packet, it will check the base context is still in FO/SO state. If the base is not valid, the compressor how to re-select another valid context as the base and sent CONTEXT-UPDATE. If the compressor can not find any valid context, it need send IR/IR-DYN packet.

As to handover, the compressor and decompressor MUST re-initialize the context when receiving signal CONTEXT_REINITIALIZATION.


> -----Original Message-----
> From: Qian Zhang [mailto:qianz@microsoft.com] 
> Sent: Tuesday, April 30, 2002 12:27 PM
> To: rohc@ietf.org
> Subject: [rohc] ROHC-TCP issue: U/B mode, mode transition, and MSN
> 
> 
> Dear ROHC-TCPers,
>  
> We are working on updating the ROHC-TCP draft according to 
> what was discussed at the Minneapolis meeting. 
> We would like to discuss the following issues in separate 
> email thread. 1. U/B mode, mode transition, and MSN issues 2. 
> Context replication/updating issue, especially in U-mode
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


From rohc-admin@ietf.org  Tue Apr 30 04:28:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10712
	for ; Tue, 30 Apr 2002 04:28:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06169;
	Tue, 30 Apr 2002 04:23:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06142
	for ; Tue, 30 Apr 2002 04:23:21 -0400 (EDT)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10589
	for ; Tue, 30 Apr 2002 04:23:14 -0400 (EDT)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <2V2R478Q>; Tue, 30 Apr 2002 09:22:10 +0100
Message-ID: <76C92FBBFB58D411AE760090271ED418036DD97C@rsys002a.roke.co.uk>
From: "McCann, Stephen" 
To: rohc@ietf.org
Subject: RE: [rohc] Invitation to EPIC-lite Interoperability Trials
Date: Tue, 30 Apr 2002 09:22:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression 
X-BeenThere: rohc@ietf.org


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Of course, I should have said 'Interoperability Trials'.

Apologies to you all !

Regards

Stephen McCann

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc