From mailnull@www1.ietf.org Mon Jun 2 11:13:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11209 for ; Mon, 2 Jun 2003 11:13:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52FCsB23319 for rohc-archive@odin.ietf.org; Mon, 2 Jun 2003 11:12:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FCsB23316 for ; Mon, 2 Jun 2003 11:12:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11191 for ; Mon, 2 Jun 2003 11:12:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mqxn-0003nL-00 for rohc-web-archive@ietf.org; Mon, 02 Jun 2003 11:11:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mqxm-0003nF-00 for rohc-web-archive@ietf.org; Mon, 02 Jun 2003 11:11:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FCNB23259; Mon, 2 Jun 2003 11:12:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52F57B21981 for ; Mon, 2 Jun 2003 11:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10946 for ; Mon, 2 Jun 2003 11:05:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MqqC-0003iO-00 for rohc@ietf.org; Mon, 02 Jun 2003 11:03:16 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19MqqB-0003hy-00 for rohc@ietf.org; Mon, 02 Jun 2003 11:03:15 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jun 2003 16:04:29 +0100 Message-ID: From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , micke@cs.arizona.edu, Lars-Erik.Jonsson@epl.ericsson.se, rohc@ietf.org Subject: RE: [rohc] linux constant IP ID field can't be compressed in prof ile 0x0001? Date: Mon, 2 Jun 2003 16:04:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I'm confused - is this a part of the final standard? My interpretation of RFC 3095 is that the compressor subtracts the sequence number from the IP-ID, and then sends the resulting offset using W-LSB encoding. The decompressor reconstructs the original IP-ID by decoding the offset and then adding the sequence number. In particular, if the decompressor receives 0 LSBs of offset, it will always assume that the offset is the same as the value stored in the context - i.e. that the IP-ID is going up by 1 in every successive packet. Regards, Richard > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: Friday, May 30, 2003 8:14 PM > To: micke@cs.arizona.edu; Lars-Erik.Jonsson@epl.ericsson.se; > rohc@ietf.org > Subject: RE: [rohc] linux constant IP ID field can't be compressed in > profile 0x0001? > > > > Since the IP ID field being constant is clearly a pattern, it seems > > reasonable to demand that this pattern should be detected in the normal > > way patterns are detected. Thus, even if the existing WLSB encoding doesn't > > compress the constantly zero field very well, the compressor would still > > be able to send type 0 headers and the decompressor should be able do > > decompress them. Also for profile 0x0001. > > > > I believe Zhigang said this about a year ago, and I don't recall any > > protests at that time. Have we since decided to not recognize this pattern? > > Thanks for pointing this out, Micke. I cannot remember when I said that > (probably 2 years ago?) but you're certainly right. > > In this case, the pattern of (IP-ID - SN) is slope = -1. So, it only takes > two headers (successfully decompressed) for the decompressor to detect the > pattern. Considering possible packet loss, the compressor only need to send > a few (>2) non-type-0 headers. The overhead due to inefficient IP-ID offset > encoding only occurs in those headers. In fact, since a few IR packets > (carrying the full value of IP-ID) have to be sent at the beginning of a > packet flow anyway, there is no additional cost to handle this particular > case. > > BR, > Zhigang > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Jun 3 04:01:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22671 for ; Tue, 3 Jun 2003 04:01:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5380al18647 for rohc-archive@odin.ietf.org; Tue, 3 Jun 2003 04:00:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5380aB18644 for ; Tue, 3 Jun 2003 04:00:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22648 for ; Tue, 3 Jun 2003 04:00:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N6gw-0002sE-00 for rohc-web-archive@ietf.org; Tue, 03 Jun 2003 03:58:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N6gw-0002sB-00 for rohc-web-archive@ietf.org; Tue, 03 Jun 2003 03:58:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5380HB18620; Tue, 3 Jun 2003 04:00:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h537xpB18538 for ; Tue, 3 Jun 2003 03:59:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22619 for ; Tue, 3 Jun 2003 03:59:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N6gD-0002rr-00 for rohc@ietf.org; Tue, 03 Jun 2003 03:58:01 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19N6gC-0002rn-00 for rohc@ietf.org; Tue, 03 Jun 2003 03:58:01 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h537xlT3002598 for ; Tue, 3 Jun 2003 09:59:47 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 3 Jun 2003 09:59:09 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] linux constant IP ID field can't be compressed in prof ile 0x0001? Date: Tue, 3 Jun 2003 09:59:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, Zhigang, and others, I agree with Richard that this is indeed confusing. What has been outlined as a potential solution by Micke and Zhigang might be a good way to handle this, and something we can define for new profiles. However, the profiles in 3095 do not specify this behavior, and a compressor can thus not assume that the decompressor will detect the pattern. The compressor must rather assume the opposite, and send IP-ID. We are working with standards here, solutions are important, but we must also introduce them in our standards in a proper way. Rgds, /L-E > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: den 2 juni 2003 17:04 > To: 'zhigang.c.liu@nokia.com'; micke@cs.arizona.edu; Lars-Erik Jonsson > (EAB); rohc@ietf.org > Subject: RE: [rohc] linux constant IP ID field can't be compressed in > prof ile 0x0001? > > > Hi, > > I'm confused - is this a part of the final standard? > > My interpretation of RFC 3095 is that the compressor subtracts the > sequence number from the IP-ID, and then sends the resulting offset > using W-LSB encoding. The decompressor reconstructs the original > IP-ID by decoding the offset and then adding the sequence number. In > particular, if the decompressor receives 0 LSBs of offset, it will > always assume that the offset is the same as the value stored in the > context - i.e. that the IP-ID is going up by 1 in every successive > packet. > > Regards, > > Richard > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: Friday, May 30, 2003 8:14 PM > > To: micke@cs.arizona.edu; Lars-Erik.Jonsson@epl.ericsson.se; > > rohc@ietf.org > > Subject: RE: [rohc] linux constant IP ID field can't be > compressed in > > profile 0x0001? > > > > > > > Since the IP ID field being constant is clearly a > pattern, it seems > > > reasonable to demand that this pattern should be detected > in the normal > > > way patterns are detected. Thus, even if the existing > WLSB encoding doesn't > > > compress the constantly zero field very well, the > compressor would still > > > be able to send type 0 headers and the decompressor > should be able do > > > decompress them. Also for profile 0x0001. > > > > > > I believe Zhigang said this about a year ago, and I don't > recall any > > > protests at that time. Have we since decided to not > recognize this pattern? > > > > Thanks for pointing this out, Micke. I cannot remember when > I said that > > (probably 2 years ago?) but you're certainly right. > > > > In this case, the pattern of (IP-ID - SN) is slope = -1. > So, it only takes > > two headers (successfully decompressed) for the > decompressor to detect the > > pattern. Considering possible packet loss, the compressor > only need to send > > a few (>2) non-type-0 headers. The overhead due to > inefficient IP-ID offset > > encoding only occurs in those headers. In fact, since a few > IR packets > > (carrying the full value of IP-ID) have to be sent at the > beginning of a > > packet flow anyway, there is no additional cost to handle > this particular > > case. > > > > BR, > > Zhigang > > > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Jun 4 04:21:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07649 for ; Wed, 4 Jun 2003 04:21:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h548Kc524251 for rohc-archive@odin.ietf.org; Wed, 4 Jun 2003 04:20:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548KcB24248 for ; Wed, 4 Jun 2003 04:20:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07574 for ; Wed, 4 Jun 2003 04:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTTq-0007Sw-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 04:18:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NTTp-0007Ss-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 04:18:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548KFB24228; Wed, 4 Jun 2003 04:20:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548JqB24181 for ; Wed, 4 Jun 2003 04:19:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07559 for ; Wed, 4 Jun 2003 04:19:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTT6-0007SY-00 for rohc@ietf.org; Wed, 04 Jun 2003 04:18:00 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19NTT5-0007SU-00 for rohc@ietf.org; Wed, 04 Jun 2003 04:17:59 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h548Jm0J018409 for ; Wed, 4 Jun 2003 10:19:48 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGJFDTM; Wed, 4 Jun 2003 10:19:07 +0200 Received: by lms001.lu.erisoft.se id KAA17096; Wed, 4 Jun 2003 10:19:43 +0200 (MET DST) Message-ID: <3EDDAB97.9C70FCE@epl.ericsson.se> Date: Wed, 04 Jun 2003 10:19:35 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "rohc@ietf.org" Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id KAA17096 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h548JqB24182 Subject: [rohc] ROHC-TCP: Update and some topics to be discussed Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h548KFB24228 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h548KcB24248 Content-Transfer-Encoding: 8bit ROHCers, The discussions regarding the ROHC-TCP profile need to be restarted on this mailing list. Let me try to kickstart this... An updated version of the draft describing the ROHC profile of TCP, , has been submitted. The following has been updated: - The normative section on context replication has been removed. Instead, the definition of the context replication mechanism has been submitted in a separate draft, mainly for clarity. - A basic structure for the IR/IR-DYN packets has been proposed. This structure uses static and dynamic chains. See Section 5.5.1. See also issue #3 later in this mail. - A basic structure for the IR-REPLICATE packet has been proposed. It follows the structure suggested in the context replication draft. See Section 5.5.3. See also issue #2 later in this mail. - Feedback format and options for ROHC-TCP has been defined. See Section 5.5.4. - Section 6 - Implementation parameter - has been removed. Please comment on these changes and the updated version in general. For the TCP profile to move forward, I have tried to summarize some of the topics that require further discussions on the mailing list: 1) Packet formats for ROHC-TCP, two alternatives: o Use ROHC-FN, and how to include the packet formats in the normative part of the TCP draft, or; o Use box or list notation with corresponding normative text describing how to encode and decode each field in the header, as in RFC-3095. 2) Context replication (See the separate draft) 3) IR/IR-DYN format for ROHC-TCP The content of Section 5.5.1 is a suggestion from the editor, for the purpose of providing grounds for discussions. This section does not represent a consensus and the following needs to be addressed: o Should we use static and dynamic chains, as in 3095? o Compression of TCP options for IR/IR-DYN o Compression of other TCP fields in IR/IR-DYN: - "data offset" is redundant - "IP protocol" can be derived from the profile number - "IP version" -> only two possible values, only one bit is required. - "TTL", particularly when compressing over the first hop - "MSN", could be LSB coded 4) Master Sequence Number (MSN) o initialization of MSN (0?) o compression of MSN within the packet format (LSB coded?) So please feel very welcome to jump into any of these questions. It would be good to be capable of moving forward rapidly so that a new update can be generated in time for the Vienna meeting. Thanks! Regards, /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 70 609 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Jun 4 10:43:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24106 for ; Wed, 4 Jun 2003 10:43:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54Eh0f22142 for rohc-archive@odin.ietf.org; Wed, 4 Jun 2003 10:43:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EgxB22139 for ; Wed, 4 Jun 2003 10:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24054 for ; Wed, 4 Jun 2003 10:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZRo-0003fs-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 10:41:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZRo-0003fp-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 10:41:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EgPB22116; Wed, 4 Jun 2003 10:42:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EfQB22084 for ; Wed, 4 Jun 2003 10:41:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23958 for ; Wed, 4 Jun 2003 10:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZQJ-0003ee-00 for rohc@ietf.org; Wed, 04 Jun 2003 10:39:31 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19NZQI-0003eY-00 for rohc@ietf.org; Wed, 04 Jun 2003 10:39:30 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2003 15:41:17 +0100 Message-ID: From: "Price, Richard" To: "'Ghyslain Pelletier'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Wed, 4 Jun 2003 15:41:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h54EgPB22116 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54EgxB22139 Content-Transfer-Encoding: 8bit Hi, Please find attached some comments on Topic 2 (the context replication mechanism). Regards, Richard ------------------------------------------------------------ Page 1: "context replication, an alternative to the context initialization procedure found in ROHC" I'd say "complement" rather than "alternative", as the context replication mechanism works in conjunction with the existing context establishment mechanisms. Page 3: "as each new packet stream requires the entire headers to be sent initially" Pedantic comment - we can avoid sending the entire header even in the IR packet, as a small number of fields can be inferred at the decompressor (e.g. IP Payload Length etc.). Page 4: "The fundamentals of general header compression may be found in [RFC-3095]. These are assumed to be understood throughout this document." I'd like to clarify the above a little further. Is it only necessary to understand the profile-independent parts of RFC 3095, or is knowledge of the four specific profiles also required to implement context replication? Page 5: "Note however that this cannot provide the guarantee that the selected context is still part of the state managed by the decompressor when the IR-REPLICATE will be received." Another potential pitfall with the context replication mechanism is that the base context may become corrupted in the interval between the decompressor sending an ACK for the base context, and the ACK being received by the compressor. This would lead the compressor to incorrectly assume that the base context is ok to use for context replication, even though it has been damaged at the decompressor. Page 5: "However, because [RFC-3095] does not explicitly define context state management between compressor and decompressor, and in particular for connection-oriented flows (e.g. TCP), only a high degree of confidence can be achieved when selecting a base context." Do you mean that the decompressor may have chosen to discard the base context (e.g. due to memory constraints)? Page 6: "otherwise the base context is overwritten with the new context by the replication process." If we set the base context equal to the current context, is it still the case that we need to acknowledge the base context using a feedback packet? It might be useful to offer the IR-REPLICATE packet as an ordinary packet format, which can be used to send compressed headers even in the unidirectional case. Page 6: "Upon reception of a STATIC-NACK, the compressor MUST transit back to its initial no context state and SHOULD refrain from sending IR-REPLICATE packets using the same base context." How does the above interact with the robustness mechanisms of the base context itself? For example, if the compressor continues to use the base context and continues to receive positive ACKs in the normal manner, is it ok to assume that the base context is actually valid (and hence that the IR-REPLICATE packet itself is where the error occurred)? Conversely, would it be possible for the compressor to take a STATIC-NACK for the newly replicated context as evidence that something is wrong with the base context? It could use this information to influence the state machine of the base context, e.g. by causing it to transit to a lower state. Page 6: "Upon reception of a NACK, the compressor may assume that the static part of the decompressor context is valid but that the dynamic part is invalid, and take actions accordingly." Again, could this also be used by the compressor as evidence that something is wrong with the base context? Page 7: "Specifically, when the decompressor fails to validate the context following the decompression of one or more initial IR-REPLICATE packets, it MUST invalidate the context and remain in its initial state. In addition, the decompressor SHOULD send a STATIC-NACK." This logic is fine for O-mode and B-mode, but I think that different logic is required in the case of R-mode. From RFC 3095: "The decompressor SHOULD NOT send STATIC-NACK(R) when receiving an IR packet that fails the CRC check, as the compressor will stay in IR state and thus continue sending IR packets until a valid ACK is received" The above also applies to an IR-REPLICATE packet, so the decompressor SHOULD NOT send a STATIC-NACK in this case. Page 7: "The decompressor SHOULD send an ACK when it succeeds to validate the context as a result of the decompression of one or more IR-REPLICATE packets." For R-mode, the above logic needs to be much more precisely defined (taking into account the "Sparse ACK" mechanism). Page 8: "The static and dynamic chains of IR packets contains an uncompressed representation of the original header." This sentence is talking about the profile-independent portion of the IR-REPLICATE packet, so I wouldn't mention the concept of a static and dynamic "chain" (as this is profile-specific). Page 10: "It is not recommended to use this packet to repair a damaged context." Are there any specific problems that can arise when repairing a damaged context using the IR-REPLICATE packet (as opposed to, say, a vanilla IR packet)? Page 10: "The IR-REPLICATE has the following general format..." I think that in the most general case the format of the IR-REPLICATE packet should be identical to the general format of the IR packet (Section 5.2.3 of RFC 3095). In particular, the static and dynamic replication chains may or may not be present depending on the specific profile. Page 11: "The presence of a payload is inferred from the packet length." As above, I think that whether to do this or not is up to the specific profile. Page 13: "Replication of the IPv6 Header [RFC-2460]" As well as the listed fields, why not replicate the Traffic Class and Hop Limit as well? Page 13: "Flow Label must not be used, i.e. this field must be all '0's." Would it be possible to create two contexts for the same flow (in which case the Flow Label is replicable but non-zero)? Page 13: "Next Header" Any thoughts on whether it would be possible to extend the replication mechanism to handle the complete list of extension headers? Potentially we could replicate the Next Header field for every header in the chain - might be a considerable saving if the chain contains several extension headers. Page 14: "[RFC-30905, section 5.7.7.8]." I'm not sure we've reached thirty thousand RFCs just yet ;-) Page 14: "Replication of the IPv4 Header [RFC-791]" We could also consider the Type of Service, Time to Live and IP-ID fields for replication. Page 16: "Is it possible to identify a useful scenario where replication of the UDP part of a context is desirable? It is not clear how much value there is the UDP header. For UDP, the static and dynamic chains found in [RFC-3095] could be used." Replicating the UDP context might be useful when running ROHC over a link where sending a large IR packet is extremely expensive. An example of such a link is a fixed-bandwidth speech channel, where the only way to send a ROHC header containing more than a certain fixed number of bytes is to discard some of the payload data (at a cost of reduced speech quality). > -----Original Message----- > From: Ghyslain Pelletier [mailto:Ghyslain.Pelletier@epl.ericsson.se] > Sent: Wednesday, June 04, 2003 9:20 AM > To: rohc@ietf.org > Subject: [rohc] ROHC-TCP: Update and some topics to be discussed > > > ROHCers, > > The discussions regarding the ROHC-TCP profile need to be restarted on > this mailing list. Let me try to kickstart this... > > An updated version of the draft describing the ROHC profile of TCP, > , has been submitted. The following has been > updated: > > - The normative section on context replication has been removed. > Instead, the definition of the context replication mechanism > has been submitted in a separate draft, mainly for clarity. > > - A basic structure for the IR/IR-DYN packets has been proposed. > This structure uses static and dynamic chains. See Section 5.5.1. > See also issue #3 later in this mail. > > - A basic structure for the IR-REPLICATE packet has been proposed. > It follows the structure suggested in the context replication draft. > See Section 5.5.3. See also issue #2 later in this mail. > > - Feedback format and options for ROHC-TCP has been defined. > See Section 5.5.4. > > - Section 6 - Implementation parameter - has been removed. > > Please comment on these changes and the updated version in general. > > For the TCP profile to move forward, I have tried to summarize some of > the topics that require further discussions on the mailing list: > > 1) Packet formats for ROHC-TCP, two alternatives: > > o Use ROHC-FN, and how to include the packet formats in the > normative part of the TCP draft, or; > o Use box or list notation with corresponding normative text > describing how to encode and decode each field in the header, > as in RFC-3095. > > 2) Context replication (See the separate draft) > > 3) IR/IR-DYN format for ROHC-TCP > > The content of Section 5.5.1 is a suggestion from the editor, for > the purpose of providing grounds for discussions. This section does > not represent a consensus and the following needs to be addressed: > > o Should we use static and dynamic chains, as in 3095? > o Compression of TCP options for IR/IR-DYN > o Compression of other TCP fields in IR/IR-DYN: > - "data offset" is redundant > - "IP protocol" can be derived from the profile number > - "IP version" -> only two possible values, only one > bit is required. > - "TTL", particularly when compressing over the first hop > - "MSN", could be LSB coded > > 4) Master Sequence Number (MSN) > o initialization of MSN (0?) > o compression of MSN within the packet format (LSB coded?) > > So please feel very welcome to jump into any of these questions. It > would be good to be capable of moving forward rapidly so that a new > update can be generated in time for the Vienna meeting. Thanks! > > Regards, > > /Ghyslain > > Ghyslain Pelletier, Dipl. Ing. > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit > > Ericsson AB, Laboratoriegränd 11 > Box 920, S-97128 Luleå, SWEDEN > Phone : +46 (0) 920 20 24 32 > Mobile: +46 (0) 70 609 27 73 > Ghyslain.Pelletier@epl.ericsson.se > http://www.ericsson.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 mailnull@www1.ietf.org Wed Jun 4 12:23:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29651 for ; Wed, 4 Jun 2003 12:23:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54GMbd31440 for rohc-archive@odin.ietf.org; Wed, 4 Jun 2003 12:22:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GMbB31437 for ; Wed, 4 Jun 2003 12:22:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29622 for ; Wed, 4 Jun 2003 12:22:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nb0H-0005BJ-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 12:20:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nb0G-0005BG-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 12:20:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GM7B31390; Wed, 4 Jun 2003 12:22:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GJuB31256 for ; Wed, 4 Jun 2003 12:19:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29572 for ; Wed, 4 Jun 2003 12:19:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Naxg-0005A5-00 for rohc@ietf.org; Wed, 04 Jun 2003 12:18:04 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Naxf-00059g-00 for rohc@ietf.org; Wed, 04 Jun 2003 12:18:03 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2003 17:19:22 +0100 Message-ID: From: "Price, Richard" To: rohc@ietf.org Date: Wed, 4 Jun 2003 17:19:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Problem with RFC 3095 Extension Header encoding Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I'm currently attempting to add support for IP Extension Headers to our ROHC-TCP implementation - the plan is to reuse the existing packet formats from RFC 3095. However, I'm having some difficulty decoding the compressed versions of the AH, ESP and GRE Sequence Numbers. What isn't clear from the standard is the following: 1. What interpretation interval should I use to decode the sequence number LSBs? 2. Should the decoded sequence number be treated as an absolute value, or as an offset from the RTP Sequence Number? If I've missed the relevant text in RFC 3095, please let me know! Thanks, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Jun 4 17:58:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14536 for ; Wed, 4 Jun 2003 17:58:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54Lvul24393 for rohc-archive@odin.ietf.org; Wed, 4 Jun 2003 17:57:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54LvtB24390 for ; Wed, 4 Jun 2003 17:57:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14518 for ; Wed, 4 Jun 2003 17:57:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NgEj-0000pq-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 17:56:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NgEi-0000pn-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 17:56:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54LvRB24374; Wed, 4 Jun 2003 17:57:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54LuYB24345 for ; Wed, 4 Jun 2003 17:56:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14491 for ; Wed, 4 Jun 2003 17:56:28 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NgDP-0000pb-00 for rohc@ietf.org; Wed, 04 Jun 2003 17:54:39 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NgDO-0000pY-00 for rohc@ietf.org; Wed, 04 Jun 2003 17:54:38 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h54LuSW03164 for ; Thu, 5 Jun 2003 00:56:28 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Jun 2003 00:56:28 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 00:56:28 +0300 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 16:56:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Wed, 4 Jun 2003 16:56:03 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139885A@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-TCP: Update and some topics to be discussed Thread-Index: AcMqcioFSLwIXY+4S0OBI+kJmu5VEwAXfQ1Q To: , X-OriginalArrivalTime: 04 Jun 2003 21:56:03.0932 (UTC) FILETIME=[17F491C0:01C32AE4] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54LuYB24346 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h54LvRB24374 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54LvtB24390 Content-Transfer-Encoding: 8bit Hi Gyslain, The following are my comments on the context replication draft (draft-pelletier-rohc-context-replication-00.txt): - Section 3.2.2: What is "OPTIONAL improved forward transition"? I was not able to find any description for this term. - Section 3.2.2.1 - last two paras: NACK is not sent in response to IR-REPLICATE. Instead, it looks like that it is a general failure information procedure for informing decompression of a subsequent packet not IR-REPLICATE. I think these two paras are irrelevant to context replication. I'd suggest to either take out these paras or explicitly mention that this is a general failure procedure. - Section 3.3.2 - Third para: Could you please clarify when the compressor will be sending IR-REPLICATE packets as subsequent packets after receiving ACK for successful decompression of the initial IR-REPLICATE. The decompressor after successfully validating IR-REPLICATE will send ACK, which moves the compressor from IR to CO state (taking ROHC-TCP state machine). I think in this state the compressor will be sending compressed packets not IR-REPLICATE. - I think we can improve on failure mechanism mentioned in the above two sections. The draft mentions that if the decompression of IR-REPLICATE fails, the decompressor will send STATIC NACK and the compressor MUST refrain from IR-REPLICATE, in other words use IR packets. Moving to IR means sending more bytes compared to IR-REPLICATE, hence degrading compression efficiency. If the decompression has failed due to transmission error of IR-REPLICATE (case-1), then the decompressor is unnecessarily asking for IR. It is better to ask for the retransmission of IR-REPLICATE and gain more compression efficiency. Not to mention, retransmitting an already encoded packet would be faster for the compressor. It is also possible that the decompression has failed because of the corruption in the base context (case-2). In case-2 we definitely want to move to the IR packet, since there is no way to fix it without sending full header. I'd propose that the decompressor should differentiate between the two cases. It can be done if we increase the coverage of 8-bit CRC (section 3.4.1.2)to cover static and dynamic chain also. The CRC of an IR or IR-DYN covers the whole IR packet, excluding payload (section 5.9.2 of RFC 3095). The proposed change in 8-bit CRC is more in line with the IR and IR-DYN CRC. The logic would work something like this: - if 7-bit CRC failed, send STATIC-NACK - if 8-bit CRC fails, send another NACK (let's call it REP-NACK). We could differentiate a REP-NACK from a regular NACK by using feedback options in the FEEDBACK-2 format and make this option available to other profiles besides TCP. We could have used NACK such that a NACK in response to IR-REPLICATE would ask compressor to resend IR-REPLICATE. But it seems like that the draft has a different use of this NACK (section 3.3.2). Section 3.4.1 - third para: The way I understood this para is that the 8-bit CRC could cover entire IR header but a profile may not do that and the reason is in section 5.2.6 of RFC 3095. I was unable to find the explanation in the reference, could you please explain this limitation. Section 3.4.2 - IR-REPLICATE format figure: I think it would be more clear to show 7-bit CRC and Base CID in the figure. These fields are described but are not shown in the figure. Appendix A: Is this the intention that the formats mentioned in this Appendix will become standardized format? If that is the case, then I would suggest to put these formats in the main body of the draft not in appendix. A.1: Why didn't we define a flag for marking Traffic Class as replicable? Is this because adding a bit would mean adding a byte and that would exactly be the saving in the Traffic class case? A.2: The two spare bits left in the first byte can be used for the replication flags for Type of Service and Identification fields. This will not cause any addition in the packet size. Could you please define the spare bits as the flags. Regards, Yousuf -----Original Message----- From: ext Ghyslain Pelletier [mailto:Ghyslain.Pelletier@epl.ericsson.se] Sent: Wednesday, June 04, 2003 3:20 AM To: rohc@ietf.org Subject: [rohc] ROHC-TCP: Update and some topics to be discussed ROHCers, The discussions regarding the ROHC-TCP profile need to be restarted on this mailing list. Let me try to kickstart this... An updated version of the draft describing the ROHC profile of TCP, , has been submitted. The following has been updated: - The normative section on context replication has been removed. Instead, the definition of the context replication mechanism has been submitted in a separate draft, mainly for clarity. - A basic structure for the IR/IR-DYN packets has been proposed. This structure uses static and dynamic chains. See Section 5.5.1. See also issue #3 later in this mail. - A basic structure for the IR-REPLICATE packet has been proposed. It follows the structure suggested in the context replication draft. See Section 5.5.3. See also issue #2 later in this mail. - Feedback format and options for ROHC-TCP has been defined. See Section 5.5.4. - Section 6 - Implementation parameter - has been removed. Please comment on these changes and the updated version in general. For the TCP profile to move forward, I have tried to summarize some of the topics that require further discussions on the mailing list: 1) Packet formats for ROHC-TCP, two alternatives: o Use ROHC-FN, and how to include the packet formats in the normative part of the TCP draft, or; o Use box or list notation with corresponding normative text describing how to encode and decode each field in the header, as in RFC-3095. 2) Context replication (See the separate draft) 3) IR/IR-DYN format for ROHC-TCP The content of Section 5.5.1 is a suggestion from the editor, for the purpose of providing grounds for discussions. This section does not represent a consensus and the following needs to be addressed: o Should we use static and dynamic chains, as in 3095? o Compression of TCP options for IR/IR-DYN o Compression of other TCP fields in IR/IR-DYN: - "data offset" is redundant - "IP protocol" can be derived from the profile number - "IP version" -> only two possible values, only one bit is required. - "TTL", particularly when compressing over the first hop - "MSN", could be LSB coded 4) Master Sequence Number (MSN) o initialization of MSN (0?) o compression of MSN within the packet format (LSB coded?) So please feel very welcome to jump into any of these questions. It would be good to be capable of moving forward rapidly so that a new update can be generated in time for the Vienna meeting. Thanks! Regards, /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 70 609 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.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 mailnull@www1.ietf.org Wed Jun 4 19:26:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17246 for ; Wed, 4 Jun 2003 19:26:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54NQ8h29863 for rohc-archive@odin.ietf.org; Wed, 4 Jun 2003 19:26:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54NQ7B29860 for ; Wed, 4 Jun 2003 19:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17206 for ; Wed, 4 Jun 2003 19:26:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nhc7-0001A7-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 19:24:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nhc6-0001A4-00 for rohc-web-archive@ietf.org; Wed, 04 Jun 2003 19:24:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54NPdB29816; Wed, 4 Jun 2003 19:25:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54NOCB29682 for ; Wed, 4 Jun 2003 19:24:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17115 for ; Wed, 4 Jun 2003 19:24:08 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NhaF-00018c-00 for rohc@ietf.org; Wed, 04 Jun 2003 19:22:19 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19NhaA-00018Z-00 for rohc@ietf.org; Wed, 04 Jun 2003 19:22:18 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h54NO3121238 for ; Wed, 4 Jun 2003 18:24:03 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Jun 2003 18:24:03 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 16:22:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Wed, 4 Jun 2003 18:22:43 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139885B@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-TCP: Update and some topics to be discussed Thread-Index: AcMqp7CUXD43iDiIQdugFdZeNNvVswAPcYVg To: , , X-OriginalArrivalTime: 04 Jun 2003 23:22:44.0259 (UTC) FILETIME=[33977F30:01C32AF0] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54NOCB29683 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h54NPdB29816 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54NQ7B29860 Content-Transfer-Encoding: 8bit Hi, I have some thoughts on some of the Richard's comments. Please search for [Yousuf] below. Cheers, Yousuf -----Original Message----- From: ext Price, Richard [mailto:richard.price@roke.co.uk] Sent: Wednesday, June 04, 2003 9:41 AM To: 'Ghyslain Pelletier'; rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Hi, Please find attached some comments on Topic 2 (the context replication mechanism). Regards, Richard ------------------------------------------------------------ Page 1: "context replication, an alternative to the context initialization procedure found in ROHC" I'd say "complement" rather than "alternative", as the context replication mechanism works in conjunction with the existing context establishment mechanisms. Page 3: "as each new packet stream requires the entire headers to be sent initially" Pedantic comment - we can avoid sending the entire header even in the IR packet, as a small number of fields can be inferred at the decompressor (e.g. IP Payload Length etc.). Page 4: "The fundamentals of general header compression may be found in [RFC-3095]. These are assumed to be understood throughout this document." I'd like to clarify the above a little further. Is it only necessary to understand the profile-independent parts of RFC 3095, or is knowledge of the four specific profiles also required to implement context replication? Page 5: "Note however that this cannot provide the guarantee that the selected context is still part of the state managed by the decompressor when the IR-REPLICATE will be received." Another potential pitfall with the context replication mechanism is that the base context may become corrupted in the interval between the decompressor sending an ACK for the base context, and the ACK being received by the compressor. This would lead the compressor to incorrectly assume that the base context is ok to use for context replication, even though it has been damaged at the decompressor. Page 5: "However, because [RFC-3095] does not explicitly define context state management between compressor and decompressor, and in particular for connection-oriented flows (e.g. TCP), only a high degree of confidence can be achieved when selecting a base context." Do you mean that the decompressor may have chosen to discard the base context (e.g. due to memory constraints)? Page 6: "otherwise the base context is overwritten with the new context by the replication process." If we set the base context equal to the current context, is it still the case that we need to acknowledge the base context using a feedback packet? It might be useful to offer the IR-REPLICATE packet as an ordinary packet format, which can be used to send compressed headers even in the unidirectional case. Page 6: "Upon reception of a STATIC-NACK, the compressor MUST transit back to its initial no context state and SHOULD refrain from sending IR-REPLICATE packets using the same base context." How does the above interact with the robustness mechanisms of the base context itself? For example, if the compressor continues to use the base context and continues to receive positive ACKs in the normal manner, is it ok to assume that the base context is actually valid (and hence that the IR-REPLICATE packet itself is where the error occurred)? Conversely, would it be possible for the compressor to take a STATIC-NACK for the newly replicated context as evidence that something is wrong with the base context? It could use this information to influence the state machine of the base context, e.g. by causing it to transit to a lower state. [Yousuf] I think it is possible to use STATIC-NACK for indicating corruption in the base context, and another NACK for indicating transmission error in IR-REPLICATE packet. We have two CRCs. 7-bit CRC covers the original uncompressed header and the 8-bit CRC covers the IR packet including static and dynamic chain (this is with the change proposed in my last email). If 8-bit CRC verifies integrity of IR-REPLICATE packet header, but the 7-bit CRC failed after decompression, then this implies that we have a problem in the base context. In this case only the decompressor will send a STATIC-NACK indicating that the decompression failed due to the problem in the base context. The compressor would discard that base context and send IR packet. Page 6: "Upon reception of a NACK, the compressor may assume that the static part of the decompressor context is valid but that the dynamic part is invalid, and take actions accordingly." Again, could this also be used by the compressor as evidence that something is wrong with the base context? Page 7: "Specifically, when the decompressor fails to validate the context following the decompression of one or more initial IR-REPLICATE packets, it MUST invalidate the context and remain in its initial state. In addition, the decompressor SHOULD send a STATIC-NACK." This logic is fine for O-mode and B-mode, but I think that different logic is required in the case of R-mode. From RFC 3095: "The decompressor SHOULD NOT send STATIC-NACK(R) when receiving an IR packet that fails the CRC check, as the compressor will stay in IR state and thus continue sending IR packets until a valid ACK is received" The above also applies to an IR-REPLICATE packet, so the decompressor SHOULD NOT send a STATIC-NACK in this case. [Yousuf] Can we solve this concern by adding IR-REPLICATE state between IR and CO state in the compressor state machine as shown below. Optimistic approach / ACK ACK +------>-------->------>------>---------+ +->-+ | Base Ctxt Avail ACK | | | | +----------+ +---->---->---------|| | | | | V | vv | v +----------+ +--------------+ +----------+ | IR State | | IR-REP State | | CO State | +----------+ +--------------+ +----------+ ^ ^ | ^ | | | +---<-----+ +-<-+ | | STATIC-NACK Timeout/NACK | | | | Timeout / NACK / STATIC-NACK | +-------<-------<-------<-------<--------+ I think this is also what context context replication is doing. Page 7: "The decompressor SHOULD send an ACK when it succeeds to validate the context as a result of the decompression of one or more IR-REPLICATE packets." For R-mode, the above logic needs to be much more precisely defined (taking into account the "Sparse ACK" mechanism). Page 8: "The static and dynamic chains of IR packets contains an uncompressed representation of the original header." This sentence is talking about the profile-independent portion of the IR-REPLICATE packet, so I wouldn't mention the concept of a static and dynamic "chain" (as this is profile-specific). Page 10: "It is not recommended to use this packet to repair a damaged context." Are there any specific problems that can arise when repairing a damaged context using the IR-REPLICATE packet (as opposed to, say, a vanilla IR packet)? Page 10: "The IR-REPLICATE has the following general format..." I think that in the most general case the format of the IR-REPLICATE packet should be identical to the general format of the IR packet (Section 5.2.3 of RFC 3095). In particular, the static and dynamic replication chains may or may not be present depending on the specific profile. Page 11: "The presence of a payload is inferred from the packet length." As above, I think that whether to do this or not is up to the specific profile. Page 13: "Replication of the IPv6 Header [RFC-2460]" As well as the listed fields, why not replicate the Traffic Class and Hop Limit as well? Page 13: "Flow Label must not be used, i.e. this field must be all '0's." Would it be possible to create two contexts for the same flow (in which case the Flow Label is replicable but non-zero)? Page 13: "Next Header" Any thoughts on whether it would be possible to extend the replication mechanism to handle the complete list of extension headers? Potentially we could replicate the Next Header field for every header in the chain - might be a considerable saving if the chain contains several extension headers. Page 14: "[RFC-30905, section 5.7.7.8]." I'm not sure we've reached thirty thousand RFCs just yet ;-) Page 14: "Replication of the IPv4 Header [RFC-791]" We could also consider the Type of Service, Time to Live and IP-ID fields for replication. Page 16: "Is it possible to identify a useful scenario where replication of the UDP part of a context is desirable? It is not clear how much value there is the UDP header. For UDP, the static and dynamic chains found in [RFC-3095] could be used." Replicating the UDP context might be useful when running ROHC over a link where sending a large IR packet is extremely expensive. An example of such a link is a fixed-bandwidth speech channel, where the only way to send a ROHC header containing more than a certain fixed number of bytes is to discard some of the payload data (at a cost of reduced speech quality). > -----Original Message----- > From: Ghyslain Pelletier [mailto:Ghyslain.Pelletier@epl.ericsson.se] > Sent: Wednesday, June 04, 2003 9:20 AM > To: rohc@ietf.org > Subject: [rohc] ROHC-TCP: Update and some topics to be discussed > > > ROHCers, > > The discussions regarding the ROHC-TCP profile need to be restarted on > this mailing list. Let me try to kickstart this... > > An updated version of the draft describing the ROHC profile of TCP, > , has been submitted. The following has been > updated: > > - The normative section on context replication has been removed. > Instead, the definition of the context replication mechanism > has been submitted in a separate draft, mainly for clarity. > > - A basic structure for the IR/IR-DYN packets has been proposed. > This structure uses static and dynamic chains. See Section 5.5.1. > See also issue #3 later in this mail. > > - A basic structure for the IR-REPLICATE packet has been proposed. > It follows the structure suggested in the context replication draft. > See Section 5.5.3. See also issue #2 later in this mail. > > - Feedback format and options for ROHC-TCP has been defined. > See Section 5.5.4. > > - Section 6 - Implementation parameter - has been removed. > > Please comment on these changes and the updated version in general. > > For the TCP profile to move forward, I have tried to summarize some of > the topics that require further discussions on the mailing list: > > 1) Packet formats for ROHC-TCP, two alternatives: > > o Use ROHC-FN, and how to include the packet formats in the > normative part of the TCP draft, or; > o Use box or list notation with corresponding normative text > describing how to encode and decode each field in the header, > as in RFC-3095. > > 2) Context replication (See the separate draft) > > 3) IR/IR-DYN format for ROHC-TCP > > The content of Section 5.5.1 is a suggestion from the editor, for > the purpose of providing grounds for discussions. This section does > not represent a consensus and the following needs to be addressed: > > o Should we use static and dynamic chains, as in 3095? > o Compression of TCP options for IR/IR-DYN > o Compression of other TCP fields in IR/IR-DYN: > - "data offset" is redundant > - "IP protocol" can be derived from the profile number > - "IP version" -> only two possible values, only one > bit is required. > - "TTL", particularly when compressing over the first hop > - "MSN", could be LSB coded > > 4) Master Sequence Number (MSN) > o initialization of MSN (0?) > o compression of MSN within the packet format (LSB coded?) > > So please feel very welcome to jump into any of these questions. It > would be good to be capable of moving forward rapidly so that a new > update can be generated in time for the Vienna meeting. Thanks! > > Regards, > > /Ghyslain > > Ghyslain Pelletier, Dipl. Ing. > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit > > Ericsson AB, Laboratoriegränd 11 > Box 920, S-97128 Luleå, SWEDEN > Phone : +46 (0) 920 20 24 32 > Mobile: +46 (0) 70 609 27 73 > Ghyslain.Pelletier@epl.ericsson.se > http://www.ericsson.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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 02:25:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08533 for ; Thu, 5 Jun 2003 02:25:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h556OkC03169 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 02:24:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h556OjB03166 for ; Thu, 5 Jun 2003 02:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08518 for ; Thu, 5 Jun 2003 02:24:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19No9A-0003EY-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 02:22:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19No9A-0003EV-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 02:22:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h556OIB03124; Thu, 5 Jun 2003 02:24:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h556NVB03090 for ; Thu, 5 Jun 2003 02:23:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08504 for ; Thu, 5 Jun 2003 02:23:26 -0400 (EDT) From: Paulius.Meskauskas@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19No7y-0003EF-00 for rohc@ietf.org; Thu, 05 Jun 2003 02:21:34 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19No7x-0003EC-00 for rohc@ietf.org; Thu, 05 Jun 2003 02:21:33 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h556NOD07277 for ; Thu, 5 Jun 2003 09:23:24 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Jun 2003 09:23:23 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 09:23:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 5 Jun 2003 09:23:22 +0300 Message-ID: <19E3AC24C8317C45B6F86092F087B2200260BB9C@esebe007.ntc.nokia.com> Thread-Topic: Dynamic update of resources in SigComp Thread-Index: AcMrKuwr3cPSS34tQ5SjpYI49Nf5eA== To: X-OriginalArrivalTime: 05 Jun 2003 06:23:23.0025 (UTC) FILETIME=[F7119010:01C32B2A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h556NVB03091 Subject: [rohc] Dynamic update of resources in SigComp Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I would like to get the clarification about the the dynamic update of resources in the SigComp endpoints (I could not find the clear answer in the RFC3320). Is it possible that two SigComp endpoints using dynamic compression updates i.e. decrease or increase sms, dms or cpb values dynamically? And if it possible, how the compartments can be synchronized? best regards, paulius _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 02:37:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08730 for ; Thu, 5 Jun 2003 02:37:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h556aZw04107 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 02:36:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h556aZB04104 for ; Thu, 5 Jun 2003 02:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08721 for ; Thu, 5 Jun 2003 02:36:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NoKd-0003YG-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 02:34:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NoKc-0003YD-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 02:34:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h556a8B04093; Thu, 5 Jun 2003 02:36:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h556ZEB04054 for ; Thu, 5 Jun 2003 02:35:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08698 for ; Thu, 5 Jun 2003 02:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NoJK-0003Xy-00 for rohc@ietf.org; Thu, 05 Jun 2003 02:33:18 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19NoJJ-0003Xv-00 for rohc@ietf.org; Thu, 05 Jun 2003 02:33:17 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h556Z7T3005957; Thu, 5 Jun 2003 08:35:07 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Jun 2003 08:36:10 +0200 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'Paulius.Meskauskas@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Thu, 5 Jun 2003 08:34:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h556ZEB04055 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h556a8B04093 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h556aZB04104 Content-Transfer-Encoding: 8bit Hi, The updates of the parameters may happen at any time with the help of the returned parameters, but an endpoint is not allowed to decrease its parameters, only to keep the originals or to increase them. As you cannot force another endpoint to send its parameters, true synchronization is impossible (lack of signalling - NACK was partly introduced to eliminate this shortcoming). If a compartment is out of synchron, the only thing it can do is to fall back to the initial state, just as if nothing has happened before. BR/Zacco -----Original Message----- From: Paulius.Meskauskas@nokia.com [mailto:Paulius.Meskauskas@nokia.com] Sent: 2003. június 5. 8:23 To: rohc@ietf.org Subject: [rohc] Dynamic update of resources in SigComp Hi, I would like to get the clarification about the the dynamic update of resources in the SigComp endpoints (I could not find the clear answer in the RFC3320). Is it possible that two SigComp endpoints using dynamic compression updates i.e. decrease or increase sms, dms or cpb values dynamically? And if it possible, how the compartments can be synchronized? best regards, paulius _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 09:15:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23711 for ; Thu, 5 Jun 2003 09:15:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55DEjP03021 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 09:14:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DEjB03018 for ; Thu, 5 Jun 2003 09:14:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23698 for ; Thu, 5 Jun 2003 09:14:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NuXy-0006hJ-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 09:12:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NuXx-0006hF-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 09:12:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DEIB03002; Thu, 5 Jun 2003 09:14:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DCJB02912 for ; Thu, 5 Jun 2003 09:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23528 for ; Thu, 5 Jun 2003 09:12:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NuVb-0006fM-00 for rohc@ietf.org; Thu, 05 Jun 2003 09:10:23 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19NuVb-0006fH-00 for rohc@ietf.org; Thu, 05 Jun 2003 09:10:23 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55DCD0J007219; Thu, 5 Jun 2003 15:12:13 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGJN689; Thu, 5 Jun 2003 15:11:59 +0200 Received: by lms001.lu.erisoft.se id PAA16574; Thu, 5 Jun 2003 15:12:08 +0200 (MET DST) Message-ID: <3EDF4196.3B547DBD@epl.ericsson.se> Date: Thu, 05 Jun 2003 15:11:50 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" CC: rohc@ietf.org Subject: Re: [rohc] ROHC-TCP: Update and some topics to be discussed References: 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-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Richard, Thanks for your comments! I've also commented in-line. I will get back to the ones I haven't answered in this mail in a later mail. /Ghyslain "Price, Richard" wrote: > [snip] > ------------------------------------------------------------ > > Page 1: "context replication, an alternative to the context > initialization procedure found in ROHC" > > I'd say "complement" rather than "alternative", as the context > replication mechanism works in conjunction with the existing > context establishment mechanisms. Absolutely. Text will be fixed. > Page 3: "as each new packet stream requires the entire headers > to be sent initially" > > Pedantic comment - we can avoid sending the entire header even > in the IR packet, as a small number of fields can be inferred > at the decompressor (e.g. IP Payload Length etc.). Absolutely. I can change the wording. > Page 4: "The fundamentals of general header compression may be > found in [RFC-3095]. These are assumed to be understood > throughout this document." > > I'd like to clarify the above a little further. Is it only > necessary to understand the profile-independent parts of RFC > 3095, or is knowledge of the four specific profiles also > required to implement context replication? Ok. Will be clarified -> profile-independant parts only. > Page 5: "Note however that this cannot provide the guarantee > that the selected context is still part of the state managed > by the decompressor when the IR-REPLICATE will be received." > > Another potential pitfall with the context replication > mechanism is that the base context may become corrupted in > the interval between the decompressor sending an ACK for the > base context, and the ACK being received by the compressor. > This would lead the compressor to incorrectly assume that the > base context is ok to use for context replication, even though > it has been damaged at the decompressor. Absolutely. This is why section 3.1 (second to last paragraph) talks about "confidence". The compressor cannpt have this certitude for the reason you've just explained. I can add a sentence on this on page 5 as well. > Page 5: "However, because [RFC-3095] does not explicitly define > context state management between compressor and decompressor, > and in particular for connection-oriented flows (e.g. TCP), only > a high degree of confidence can be achieved when selecting a > base context." > > Do you mean that the decompressor may have chosen to discard the > base context (e.g. due to memory constraints)? Yes. For connection-oriented flows, this could be a possible implementation choice to save memory, and I am not sure I am willing to constraint this possibility without this being a concious decision. > Page 6: "otherwise the base context is overwritten with the new > context by the replication process." > > If we set the base context equal to the current context, is it > still the case that we need to acknowledge the base context using > a feedback packet? It might be useful to offer the IR-REPLICATE > packet as an ordinary packet format, which can be used to send > compressed headers even in the unidirectional case. It does not need to be acknowledged. Section 3.3.2. (decompressor logic) says that the decompressor should nack upon failure and should ack upon success. It was written specifically not to have to mandate either so that the IR-REPLICATE can be used as you described. Do you think that the text is not clear, or do you think that there might be a problem with the current text? [snip] [I will get back on the feedback logic - I need to parse other related comments first.] > > Page 8: "The static and dynamic chains of IR packets contains an > uncompressed representation of the original header." > > This sentence is talking about the profile-independent portion > of the IR-REPLICATE packet, so I wouldn't mention the concept > of a static and dynamic "chain" (as this is profile-specific). This makes sense. I will adjust this. I guess for now see it more as a suggestion together with the annex to exemplify a possible way of doing it, other ways to do this may be defined instead. [snip] > Page 10: "The IR-REPLICATE has the following general format..." > > I think that in the most general case the format of the > IR-REPLICATE packet should be identical to the general format > of the IR packet (Section 5.2.3 of RFC 3095). In particular, > the static and dynamic replication chains may or may not be > present depending on the specific profile. I can agree on the chains. However, I'd still like to keep the "requirements" on the profile specific part regarding the 7-bit CRC. > Page 11: "The presence of a payload is inferred from the > packet length." > > As above, I think that whether to do this or not is up to the > specific profile. Correct. > Page 13: "Replication of the IPv6 Header [RFC-2460]" > > As well as the listed fields, why not replicate the Traffic > Class and Hop Limit as well? The annex is informative and provide a possible way of structuring the IR-REPLICATE. This is meant as a suggestion. We could add replication for those two fields as well if we want so. I can update that. > Page 13: "Flow Label must not be used, i.e. this field must be > all '0's." > > Would it be possible to create two contexts for the same flow > (in which case the Flow Label is replicable but non-zero)? Please precise your thoughts on this. Right now I guess you mean removing the requirement that it be all '0's so that it can be replicated? What do you mean by "create two contexts for the same flow"? > Page 13: "Next Header" > > Any thoughts on whether it would be possible to extend the > replication mechanism to handle the complete list of extension > headers? Potentially we could replicate the Next Header field > for every header in the chain - might be a considerable saving > if the chain contains several extension headers. We can always improve to include this. Any suggestions? > Page 14: "[RFC-30905, section 5.7.7.8]." > > I'm not sure we've reached thirty thousand RFCs just yet ;-) Will we get there? ;-) > Page 14: "Replication of the IPv4 Header [RFC-791]" > > We could also consider the Type of Service, Time to Live and > IP-ID fields for replication. Yes, we could. I can update that too. > Page 16: "Is it possible to identify a useful scenario where > replication of the UDP part of a context is desirable? It is not > clear how much value there is the UDP header. For UDP, the > static and dynamic chains found in [RFC-3095] could be used." > > Replicating the UDP context might be useful when running ROHC > over a link where sending a large IR packet is extremely > expensive. An example of such a link is a fixed-bandwidth > speech channel, where the only way to send a ROHC header > containing more than a certain fixed number of bytes is to > discard some of the payload data (at a cost of reduced speech > quality). Sorry, the question in the draft was not clear. It was meant as "how much can we save for UPD and UDP-Lite, really? Is it worth it?" Thanks again for you comments. I'll get back on the other unanswered questions later. I'll try to reflect your comments properly in the next update to this draft. /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 10:02:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26091 for ; Thu, 5 Jun 2003 10:02:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55E2Uu06228 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 10:02:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55E2TB06225 for ; Thu, 5 Jun 2003 10:02:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26081 for ; Thu, 5 Jun 2003 10:02:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NvI8-0007Br-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:00:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NvI8-0007Bo-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:00:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55E25B06194; Thu, 5 Jun 2003 10:02:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55E05B06081 for ; Thu, 5 Jun 2003 10:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25973 for ; Thu, 5 Jun 2003 10:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NvFp-0007A3-00 for rohc@ietf.org; Thu, 05 Jun 2003 09:58:09 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19NvFo-00079x-00 for rohc@ietf.org; Thu, 05 Jun 2003 09:58:08 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 14:59:28 +0100 Message-ID: From: "Price, Richard" To: "'Lajos Zaccomer (ETH)'" , "'Paulius.Meskauskas@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Thu, 5 Jun 2003 14:59:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55E05B06082 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h55E25B06194 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55E2TB06225 Content-Transfer-Encoding: 8bit > The updates of the parameters may happen at any time with the > help of the returned parameters, but an endpoint is not > allowed to decrease its parameters, only to keep the > originals or to increase them. Hi, This was true for an early version of SigComp, but we remembered to fix it before publishing the final RFC ;-) An endpoint can now choose to reduce the amount of resources that it offers on-the-fly, provided that it does so in a robust manner (i.e. it needs to make sure that the remote endpoint knows that the available resources have been reduced, before it actually reclaims them). One possible way to keep the endpoints in sync is to use the SigComp Feedback mechanism. In this case, the following two steps need to be taken: 1. The endpoint sends a message announcing the reduced resources, (but does not make the actual reductions just yet). It also requests an acknowledgement of the message to be returned via the SigComp Feedback mechanism. 2. When the acknowledgement is returned, the endpoint knows that the original message has been successfully received. It can then safely reclaim the resources without causing decompression failures to occur. > As you cannot force another endpoint to send its parameters, > true synchronization is impossible True synchronisation is always impossible over an unreliable transport, but the SigComp Feedback mechanism is designed to ensure that this isn't a problem. It works much like R-mode of RFC 3095, using the following general rule: "Don't assume that any data has arrived until you get an explicit acknowledgement." So, for example, a compressor should not attempt to access a state item unless it receives an explicit acknowledgment that the state has been created by the remote endpoint. > (lack of signalling - NACK was partly introduced to eliminate > this shortcoming). The volume of signalling traffic is under the control of the compressor. If it wishes, it can use the SigComp Feedback mechanism to request the explicit acknowledgement of every single compressed message. The NACK mechanism can help endpoints to recover if they lose synchronisation - however, the SigComp Feedback mechanism is designed to prevent this from occurring in the first place! > If a compartment is out of synchron, the only thing it can do > is to fall back to the initial state, just as if nothing has > happened before. True. Note however that a pair of correctly implemented SigComp endpoints will lose synchronisation roughly once in every 2^48 compressed messages (assuming 6-byte hashes)! So if this happens regularly, it's a good indication that there's something amiss... Regards, Richard > > -----Original Message----- > From: Paulius.Meskauskas@nokia.com > [mailto:Paulius.Meskauskas@nokia.com] > Sent: 2003. június 5. 8:23 > To: rohc@ietf.org > Subject: [rohc] Dynamic update of resources in SigComp > > > Hi, > > I would like to get the clarification about the the dynamic > update of resources in the SigComp endpoints (I could not > find the clear answer in the RFC3320). > > Is it possible that two SigComp endpoints using dynamic > compression updates i.e. decrease or increase sms, > dms or cpb values dynamically? And if it possible, how > the compartments can be synchronized? > > best regards, > paulius > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 10:39:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28696 for ; Thu, 5 Jun 2003 10:39:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55Ed7M10040 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 10:39:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Ed7B10037 for ; Thu, 5 Jun 2003 10:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28655 for ; Thu, 5 Jun 2003 10:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvra-0007Tn-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:37:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nvra-0007Tk-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:37:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EcVB09976; Thu, 5 Jun 2003 10:38:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EbTB09575 for ; Thu, 5 Jun 2003 10:37:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28617 for ; Thu, 5 Jun 2003 10:37:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvq0-0007TR-00 for rohc@ietf.org; Thu, 05 Jun 2003 10:35:32 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Nvpz-0007TO-00 for rohc@ietf.org; Thu, 05 Jun 2003 10:35:31 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55EbMT3002698; Thu, 5 Jun 2003 16:37:22 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Jun 2003 16:38:26 +0200 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'Price, Richard'" Cc: "'Paulius.Meskauskas@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Thu, 5 Jun 2003 16:36:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55EbTB09576 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h55EcVB09976 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55Ed7B10037 Content-Transfer-Encoding: 8bit Hi Richard, See my comments and questions inline! Thank you for the answers in advance! BR/Zacco -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: 2003. június 5. 15:59 To: Lajos Zaccomer (ETH); 'Paulius.Meskauskas@nokia.com'; rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp > The updates of the parameters may happen at any time with the > help of the returned parameters, but an endpoint is not > allowed to decrease its parameters, only to keep the > originals or to increase them. Hi, This was true for an early version of SigComp, but we remembered to fix it before publishing the final RFC ;-) >> Where is this specified in the RFC? An endpoint can now choose to reduce the amount of resources that it offers on-the-fly, provided that it does so in a robust manner (i.e. it needs to make sure that the remote endpoint knows that the available resources have been reduced, before it actually reclaims them). One possible way to keep the endpoints in sync is to use the SigComp Feedback mechanism. In this case, the following two steps need to be taken: 1. The endpoint sends a message announcing the reduced resources, (but does not make the actual reductions just yet). It also requests an acknowledgement of the message to be returned via the SigComp Feedback mechanism. 2. When the acknowledgement is returned, the endpoint knows that the original message has been successfully received. It can then safely reclaim the resources without causing decompression failures to occur. > As you cannot force another endpoint to send its parameters, > true synchronization is impossible True synchronisation is always impossible over an unreliable transport, but the SigComp Feedback mechanism is designed to ensure that this isn't a problem. It works much like R-mode of RFC 3095, using the following general rule: "Don't assume that any data has arrived until you get an explicit acknowledgement." >> I didn't mean the unreliable layer. I meant that I cannot ask an another endpoint to send its parameters, as this activity is only a SHOULD, thus we cannot rely on this. So, for example, a compressor should not attempt to access a state item unless it receives an explicit acknowledgment that the state has been created by the remote endpoint. >> Having the ack does not mean that the state was successfully saved. It means that the sigcomp message was successfully decompressed and the application autenticated it. We have no information if the state was indeed saved. > (lack of signalling - NACK was partly introduced to eliminate > this shortcoming). The volume of signalling traffic is under the control of the compressor. If it wishes, it can use the SigComp Feedback mechanism to request the explicit acknowledgement of every single compressed message. >> I think that it was rather misleading to call the normal feedback remote compressor initiated explicit acknowledgement, as it is described in RFC 3321 as something new. But this is not the point. The normal feedback (or remote compressor initiated explicit acknowledgement) has the above detailed shortcoming. While the local endpoint initiated explicit acknowledgement has another shortcoming: there may be up to four state creates and only one of them can be explicitely acked. But unfortunately we don't know which one, as you said it was an implementation decision. In consequence, this is not reliable, too. The NACK mechanism can help endpoints to recover if they lose synchronisation - however, the SigComp Feedback mechanism is designed to prevent this from occurring in the first place! > If a compartment is out of synchron, the only thing it can do > is to fall back to the initial state, just as if nothing has > happened before. True. Note however that a pair of correctly implemented SigComp endpoints will lose synchronisation roughly once in every 2^48 compressed messages (assuming 6-byte hashes)! So if this happens regularly, it's a good indication that there's something amiss... >> This is theory. In reality, there might be other problems (e.g. the feedback is sent back, but the sate could not be saved for the state database is full or for some reason not accessible, or there might be a corrupted message that the SIP parser accepts but the state will not match) and this probablity may be considerably higher. Regards, Richard > > -----Original Message----- > From: Paulius.Meskauskas@nokia.com > [mailto:Paulius.Meskauskas@nokia.com] > Sent: 2003. június 5. 8:23 > To: rohc@ietf.org > Subject: [rohc] Dynamic update of resources in SigComp > > > Hi, > > I would like to get the clarification about the the dynamic > update of resources in the SigComp endpoints (I could not > find the clear answer in the RFC3320). > > Is it possible that two SigComp endpoints using dynamic > compression updates i.e. decrease or increase sms, > dms or cpb values dynamically? And if it possible, how > the compartments can be synchronized? > > best regards, > paulius > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 10:53:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29118 for ; Thu, 5 Jun 2003 10:53:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55EqrM10652 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 10:52:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EqrB10649 for ; Thu, 5 Jun 2003 10:52:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29098 for ; Thu, 5 Jun 2003 10:52:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nw4t-0007Zn-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:50:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nw4t-0007Zk-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:50:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EqAB10625; Thu, 5 Jun 2003 10:52:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EjoB10285 for ; Thu, 5 Jun 2003 10:45:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28870 for ; Thu, 5 Jun 2003 10:45:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvy5-0007WL-00 for rohc@ietf.org; Thu, 05 Jun 2003 10:43:53 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Nvy4-0007WI-00 for rohc@ietf.org; Thu, 05 Jun 2003 10:43:52 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55EkNbj014957; Thu, 5 Jun 2003 16:46:23 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYTBSJS; Thu, 5 Jun 2003 16:45:29 +0200 Received: by lms001.lu.erisoft.se id QAA18284; Thu, 5 Jun 2003 16:45:38 +0200 (MET DST) Message-ID: <3EDF577F.32F2CEDE@epl.ericsson.se> Date: Thu, 05 Jun 2003 16:45:20 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yousuf.Saifullah@nokia.com CC: rohc@ietf.org Subject: Re: [rohc] ROHC-TCP: Update and some topics to be discussed References: <025E7DD4182874489CC2F61EE0FA19CE0139885A@daebe004.americas.nokia.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id QAA18284 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55EjoB10286 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h55EqAB10625 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55EqrB10649 Content-Transfer-Encoding: 8bit Hi Yousuf, Thanks for your comments. Some answers in-line. I will get back to some of the issues I won't address in this mail in a later mail. Regards, /Ghyslain Yousuf.Saifullah@nokia.com wrote: > > Hi Gyslain, > > The following are my comments on the context replication draft (draft-pelletier-rohc-context-replication-00.txt): > > - Section 3.2.2: What is "OPTIONAL improved forward transition"? > I was not able to find any description for this term. This is written in the same way as in RFC-3095, section 5.4.1.1. Basically, what this means is that it is not necessary - the compressor may still transit to a higher state, but it can help such a transition to happen faster. > - Section 3.2.2.1 - last two paras: NACK is not sent in response to > IR-REPLICATE. Instead, it looks like that it is a general failure > information procedure for informing decompression of a subsequent > packet not IR-REPLICATE. I think these two paras are irrelevant to > context replication. I'd suggest to either take out these paras or > explicitly mention that this is a general failure procedure. I am not sure that I understand the first statement in the comment. What do you mean by "NACK is not sent in response to IR-REPLICATE"? I'd like you to bring some precisions so I can bring you a better answer. Section 3.3.2. of the draft states that the decompressor can send a NACK in response to an IR-REPLICATE in some cases. > - Section 3.3.2 - Third para: Could you please clarify when the > compressor will be sending IR-REPLICATE packets as subsequent packets > after receiving ACK for successful decompression of the initial > IR-REPLICATE. The decompressor after successfully validating > IR-REPLICATE will send ACK, which moves the compressor from IR to CO > state (taking ROHC-TCP state machine). I think in this state the > compressor will be sending compressed packets not IR-REPLICATE. I think that we do not prevent the IR-REPLICATE to be sent and decompressed in other states than IR state, that is we do not prevent it (and I don't think we can anyway) to be used as an ordinary packet. [snip] [I'll get back on the feedback and failure mechanism.] [I think this should be taken separately.] > > Section 3.4.1 - third para: The way I understood this para is that > the 8-bit CRC could cover entire IR header but a profile may not do > that and the reason is in section 5.2.6 of RFC 3095. I was unable to > find the explanation in the reference, could you please explain this > limitation. Recall point 10) in section 5.2.6. of RFC-3095 states: 10) If the packet type is IR, the profile indicated in the IR packet determines how it is to be processed. If the CRC fails to verify the packet, it MUST be discarded. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, no further action is taken. This is framework logic, and the IR-REPLICATE is also an IR packet. The text in the context replication draft states the consequence of that point for the IR-REPLICATE regarding the type of CRC, its presence in an IR packet (thus this applies to the IR-REPLICATE as well) and nature of what it protects (e.g. it cannot be redefined to cover say the original uncompressed header instead). Therefore only the extent of the CRC coverage can be redefined by a profile and it must meet the minimal coverage required (CID, Profile, etc. - that is at least the initial part of the packet ending with the Profile field). > Section 3.4.2 - IR-REPLICATE format figure: I think it would be more > clear to show 7-bit CRC and Base CID in the figure. These fields are > described but are not shown in the figure. The 7-bit CRC (always present) and the Base CID (if present) are both part of the profile specific information. This means that how they are to be represented in the format depends on the packet format defined by a specific profile, and this may vary from one profile to another. Therefore it would not be appropriate in my opinion to show these fields in the figure. Consider for example a profile that would define two "sets" of packet formats, one of which includes the Base CID for when the compressor wants to create a different context and keep the base context, and one that doesn't for when we want to overwrite the base context. Another profile might be defined so that the Base CID field is always present in the format. Still, it is appropriate for the text to mandate the presence of a 7-bit CRC in the packet and mention that an identifier to the Base CID may be present because these belong to the replication mechanism - their functionality and nature is defined by context replication. > Appendix A: Is this the intention that the formats mentioned in this > Appendix will become standardized format? If that is the case, then I > would suggest to put these formats in the main body of the draft not > in appendix. The appendix is informative. This is simply a suggestion to exemplify a possible structure to the IR-REPLICATE packet. Other approaches than chains (for example) might be taken. As said previously, this part is profile specific, so I am not sure how/if we can make this part normative in this document. See also my reply to Richard's comments on this. > A.1: Why didn't we define a flag for marking Traffic Class as > replicable? Is this because adding a bit would mean adding a byte and > that would exactly be the saving in the Traffic class case? This can be added without requiring another octet. We could use codes insteads of flags. As Richard pointed out, we could also add hop limit as well. I can update that. > A.2: The two spare bits left in the first byte can be used for the > replication flags for Type of Service and Identification fields. This > will not cause any addition in the packet size. Could you please > define the spare bits as the flags. Yes, I can do that. As Richard pointed out, we could also add TTL as well. Thanks for your comment. I will get back on the question I haven't answered in a later mail. /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 70 609 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 12:33:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05559 for ; Thu, 5 Jun 2003 12:33:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55GWp319469 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 12:32:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GWpB19466 for ; Thu, 5 Jun 2003 12:32:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05545 for ; Thu, 5 Jun 2003 12:32:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nxdg-0000uH-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 12:30:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nxdf-0000uC-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 12:30:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GWQB19450; Thu, 5 Jun 2003 12:32:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GVaB19408 for ; Thu, 5 Jun 2003 12:31:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05517 for ; Thu, 5 Jun 2003 12:31:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NxcT-0000ti-00 for rohc@ietf.org; Thu, 05 Jun 2003 12:29:41 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19NxcS-0000tf-00 for rohc@ietf.org; Thu, 05 Jun 2003 12:29:40 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 17:31:32 +0100 Message-ID: From: "Price, Richard" To: "'Ghyslain Pelletier'" , Yousuf.Saifullah@nokia.com Cc: rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Thu, 5 Jun 2003 17:31:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > A.1: Why didn't we define a flag for marking Traffic Class as > > replicable? Is this because adding a bit would mean adding a byte and > > that would exactly be the saving in the Traffic class case? > > This can be added without requiring another octet. We could use codes > insteads of flags. As Richard pointed out, we could also add hop limit > as well. I can update that. Hi, It might be a good idea to switch from indicator flags to indicator codes, as we save quite a few bytes due to not sending the flag bytes in every IR-REPLICATE packet. As a comparison, here's a set of IR-REPLICATE packet formats for TCP/IP, using indicator codes rather than flags: http://sigcomp.srmr.co.uk/~rjp/IR_REPLICATE.txt N.B. The packet formats are generated automatically using the OH algorithm, so we can choose the exact number of formats that are generated (22 packet formats is probably more than we need!). I also made a few other changes that might be useful for improving the efficiency of the packet formats: * Added 4 bits of MSN in every packet (I think that this will be useful for robustness). * Added replication of the IP TOS and TTL. * Added the ability to replicate the IP-ID (by sending varying numbers of LSBs). * Added the ability to infer the TCP Ack field whenever it is set to 0. * Eliminated the Data Offset (can be inferred at the decompressor). Compression ratio is pretty good - minimum packet size is now 9 bytes (plus framework overhead), compared to 18 bytes for the original proposal. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Jun 5 13:06:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06628 for ; Thu, 5 Jun 2003 13:06:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55H5jR21994 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 13:05:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H5jB21991 for ; Thu, 5 Jun 2003 13:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06594 for ; Thu, 5 Jun 2003 13:05:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny9V-0001AM-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 13:03:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ny9V-0001AJ-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 13:03:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H5IB21916; Thu, 5 Jun 2003 13:05:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H4UB21853 for ; Thu, 5 Jun 2003 13:04:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06530 for ; Thu, 5 Jun 2003 13:04:26 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny8J-000192-00 for rohc@ietf.org; Thu, 05 Jun 2003 13:02:35 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19Ny8I-00018z-00 for rohc@ietf.org; Thu, 05 Jun 2003 13:02:34 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55H4Pb03417 for ; Thu, 5 Jun 2003 12:04:25 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Jun 2003 12:04:31 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 10:03:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Thu, 5 Jun 2003 12:03:52 -0500 Message-ID: Thread-Topic: [rohc] Dynamic update of resources in SigComp Thread-Index: AcMraxpKKdHZ421BSZCqEiLGwHfgwAAD6hmA To: , , , X-OriginalArrivalTime: 05 Jun 2003 17:03:57.0713 (UTC) FILETIME=[73ED8810:01C32B84] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55H4UB21854 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Richard, > This was true for an early version of SigComp, but we remembered > to fix it before publishing the final RFC ;-) I also remember we had discussion whether to allow reducing resource dynamically. Decreasing seemed trickier than increasing. So, at one time, we disallowed it. But I cannot recall details how we reversed it later? In particular, I couldn't find text in RFC 3320 on this, or perhaps I missed it? > True synchronisation is always impossible over an unreliable > transport, but the SigComp Feedback mechanism is designed to > ensure that this isn't a problem. It works much like R-mode of > RFC 3095, using the following general rule: > > "Don't assume that any data has arrived until you get an > explicit acknowledgement." > > So, for example, a compressor should not attempt to access a state > item unless it receives an explicit acknowledgment that the state > has been created by the remote endpoint. Right. But when an endpoint reduces its SMS, even previously acknowledged state(s) may have to be deleted. Then the order of deletion is important to maintain synchronization. Presumably, state_retention_priority should be used for this purpose (i.e. lowest priority should be deleted first). But again, it this clear form RFC 3320? It only takes one or two sentences to clarify. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 02:45:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12158 for ; Fri, 6 Jun 2003 02:45:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h566inI27741 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 02:44:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566inB27738 for ; Fri, 6 Jun 2003 02:44:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12129 for ; Fri, 6 Jun 2003 02:44:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OAw6-0006tt-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 02:42:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OAw6-0006tq-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 02:42:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566iQB27695; Fri, 6 Jun 2003 02:44:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566hqB27678 for ; Fri, 6 Jun 2003 02:43:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12097 for ; Fri, 6 Jun 2003 02:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OAvB-0006tX-00 for rohc@ietf.org; Fri, 06 Jun 2003 02:41:53 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OAvA-0006tU-00 for rohc@ietf.org; Fri, 06 Jun 2003 02:41:52 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h566hdT3029791; Fri, 6 Jun 2003 08:43:39 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Jun 2003 08:43:24 +0200 Message-ID: From: "Jan Christoffersson (EAB)" To: "'zhigang.c.liu@nokia.com'" , richard.price@roke.co.uk, "Lajos Zaccomer (ETH)" , Paulius.Meskauskas@nokia.com, rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 08:43:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Folks, As far as I remember, there is only one exception to the rule that an endpoint must not decrease its resources and that is if the compressor sets the 'I' bit to 1, then it's ok for the other endpoint to reduce (or set to zero) the state memory size. Apart from this, an endpoint should never decrease its resources. As Zhigang says, reducing the available recources on the fly would make life much more complicated and this was the reason why the idea was that they should only be increased and never decreased! However, looking through RFC 3320 I cannot find that this is very clearly written. In section 3.3 it says: "Each parameter has a minimum value that MUST be offered by all receiving SigComp endpoints. Moreover, endpoints MAY offer additional resources if available; these resources can be advertised to remote endpoints using the SigComp feedback mechanism." Unfortunately, to me this is not clear enough. I agree with Zhigang that this should be made clearer. Perhaps this is something for the Implementors Guide to begin with? Regards, Jan -----Original Message----- From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] Sent: den 5 juni 2003 19:04 To: richard.price@roke.co.uk; Lajos Zaccomer (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Richard, > This was true for an early version of SigComp, but we remembered > to fix it before publishing the final RFC ;-) I also remember we had discussion whether to allow reducing resource dynamically. Decreasing seemed trickier than increasing. So, at one time, we disallowed it. But I cannot recall details how we reversed it later? In particular, I couldn't find text in RFC 3320 on this, or perhaps I missed it? > True synchronisation is always impossible over an unreliable > transport, but the SigComp Feedback mechanism is designed to > ensure that this isn't a problem. It works much like R-mode of > RFC 3095, using the following general rule: > > "Don't assume that any data has arrived until you get an > explicit acknowledgement." > > So, for example, a compressor should not attempt to access a state > item unless it receives an explicit acknowledgment that the state > has been created by the remote endpoint. Right. But when an endpoint reduces its SMS, even previously acknowledged state(s) may have to be deleted. Then the order of deletion is important to maintain synchronization. Presumably, state_retention_priority should be used for this purpose (i.e. lowest priority should be deleted first). But again, it this clear form RFC 3320? It only takes one or two sentences to clarify. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 04:00:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13497 for ; Fri, 6 Jun 2003 04:00:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h567xlC32160 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 03:59:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567xkB32157 for ; Fri, 6 Jun 2003 03:59:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13471 for ; Fri, 6 Jun 2003 03:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OC6h-0007EB-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 03:57:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OC6g-0007E8-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 03:57:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567xLB32146; Fri, 6 Jun 2003 03:59:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567wAB32112 for ; Fri, 6 Jun 2003 03:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13451 for ; Fri, 6 Jun 2003 03:58:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OC59-0007Di-00 for rohc@ietf.org; Fri, 06 Jun 2003 03:56:15 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OC58-0007Df-00 for rohc@ietf.org; Fri, 06 Jun 2003 03:56:14 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h567wibj011209; Fri, 6 Jun 2003 09:58:44 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Jun 2003 09:57:49 +0200 Message-ID: From: "Jan Christoffersson (EAB)" To: "Jan Christoffersson (EAB)" , "'zhigang.c.liu@nokia.com'" , richard.price@roke.co.uk, "Lajos Zaccomer (ETH)" , Paulius.Meskauskas@nokia.com, rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 09:57:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Correction: it should be the 'S' bit, not the 'I' bit in my reply below :-) /Jan -----Original Message----- From: Jan Christoffersson (EAB) Sent: den 6 juni 2003 08:43 To: 'zhigang.c.liu@nokia.com'; richard.price@roke.co.uk; Lajos Zaccomer (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Hi Folks, As far as I remember, there is only one exception to the rule that an endpoint must not decrease its resources and that is if the compressor sets the 'I' bit to 1, then it's ok for the other endpoint to reduce (or set to zero) the state memory size. Apart from this, an endpoint should never decrease its resources. As Zhigang says, reducing the available recources on the fly would make life much more complicated and this was the reason why the idea was that they should only be increased and never decreased! However, looking through RFC 3320 I cannot find that this is very clearly written. In section 3.3 it says: "Each parameter has a minimum value that MUST be offered by all receiving SigComp endpoints. Moreover, endpoints MAY offer additional resources if available; these resources can be advertised to remote endpoints using the SigComp feedback mechanism." Unfortunately, to me this is not clear enough. I agree with Zhigang that this should be made clearer. Perhaps this is something for the Implementors Guide to begin with? Regards, Jan -----Original Message----- From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] Sent: den 5 juni 2003 19:04 To: richard.price@roke.co.uk; Lajos Zaccomer (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Richard, > This was true for an early version of SigComp, but we remembered > to fix it before publishing the final RFC ;-) I also remember we had discussion whether to allow reducing resource dynamically. Decreasing seemed trickier than increasing. So, at one time, we disallowed it. But I cannot recall details how we reversed it later? In particular, I couldn't find text in RFC 3320 on this, or perhaps I missed it? > True synchronisation is always impossible over an unreliable > transport, but the SigComp Feedback mechanism is designed to > ensure that this isn't a problem. It works much like R-mode of > RFC 3095, using the following general rule: > > "Don't assume that any data has arrived until you get an > explicit acknowledgement." > > So, for example, a compressor should not attempt to access a state > item unless it receives an explicit acknowledgment that the state > has been created by the remote endpoint. Right. But when an endpoint reduces its SMS, even previously acknowledged state(s) may have to be deleted. Then the order of deletion is important to maintain synchronization. Presumably, state_retention_priority should be used for this purpose (i.e. lowest priority should be deleted first). But again, it this clear form RFC 3320? It only takes one or two sentences to clarify. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 04:05:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13570 for ; Fri, 6 Jun 2003 04:05:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5685Um32717 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 04:05:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5685UB32713 for ; Fri, 6 Jun 2003 04:05:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13567 for ; Fri, 6 Jun 2003 04:05:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCCE-0007Fd-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 04:03:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OCCE-0007Fa-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 04:03:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56857B32702; Fri, 6 Jun 2003 04:05:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5684YB32663 for ; Fri, 6 Jun 2003 04:04:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13547 for ; Fri, 6 Jun 2003 04:04:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCBL-0007FT-00 for rohc@ietf.org; Fri, 06 Jun 2003 04:02:39 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OCBK-0007FQ-00 for rohc@ietf.org; Fri, 06 Jun 2003 04:02:38 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5684VT3014595 for ; Fri, 6 Jun 2003 10:04:31 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Jun 2003 10:04:16 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 10:04:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > > A.1: Why didn't we define a flag for marking Traffic Class > > > as replicable? Is this because adding a bit would mean > > > adding a byte and that would exactly be the saving in the > > > Traffic class case? > > > > GP: > > This can be added without requiring another octet. We could > > use codes insteads of flags. As Richard pointed out, we could > > also add hop limit as well. I can update that. Just because it can be done does not mean it should be done. I personally think we should limit the replication possibilities to addresses (potentially including ports), as I think it would be a mistake to make this mechanism too flexible and complex. > As a comparison, here's a set of IR-REPLICATE packet formats > for TCP/IP, using indicator codes rather than flags: > > http://sigcomp.srmr.co.uk/~rjp/IR_REPLICATE.txt I know these are a little bit lengthy, but I would prefer to still get these to the list. At this point, we do not need to have many formats, discussions would rather benefit from having small sets to look at and discuss. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 04:31:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13963 for ; Fri, 6 Jun 2003 04:31:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h568UjU02160 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 04:30:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568UjB02157 for ; Fri, 6 Jun 2003 04:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13925 for ; Fri, 6 Jun 2003 04:30:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCac-0007MO-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 04:28:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OCac-0007ML-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 04:28:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568UIB02126; Fri, 6 Jun 2003 04:30:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568TZB02090 for ; Fri, 6 Jun 2003 04:29:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13898 for ; Fri, 6 Jun 2003 04:29:32 -0400 (EDT) From: Paulius.Meskauskas@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCZX-0007La-00 for rohc@ietf.org; Fri, 06 Jun 2003 04:27:39 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19OCZW-0007LX-00 for rohc@ietf.org; Fri, 06 Jun 2003 04:27:38 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h568TVD13350 for ; Fri, 6 Jun 2003 11:29:31 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 11:29:30 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 11:29:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 11:29:29 +0300 Message-ID: <19E3AC24C8317C45B6F86092F087B22001DE5B3A@esebe007.ntc.nokia.com> Thread-Topic: [rohc] Dynamic update of resources in SigComp Thread-Index: AcMsAZOoX439LdFSSD+6DXWJUddyzAAATTSw To: , , , , X-OriginalArrivalTime: 06 Jun 2003 08:29:30.0839 (UTC) FILETIME=[C0401670:01C32C05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h568TZB02091 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, I agree with Jan that endpoint must never decrease the resources. I see one possible problem with Richard's implementation suggestion: the client of the SigComp instructs the SigComp to decrease the sms of the compartment for instance due to low memory condition in the mobile terminal. But endpoint can free actually the resources after it receives an ack from the remote endpoint. It is possible that the endpoint can't decrease the resources in order to avoid synchronization problems. IMO this should not be allowed to happen in the mobile terminal. cheers, paulius > -----Original Message----- > From: ext Jan Christoffersson (EAB) > [mailto:Jan.Christoffersson@epl.ericsson.se] > Sent: 06 June, 2003 10:58 > To: Jan Christoffersson (EAB); Liu Zhigang.C (NRC/Dallas); > richard.price@roke.co.uk; Lajos Zaccomer (ETH); Meskauskas Paulius > (NMP/Helsinki); rohc@ietf.org > Subject: RE: [rohc] Dynamic update of resources in SigComp > > > Correction: it should be the 'S' bit, not the 'I' bit in my > reply below :-) > > /Jan > > -----Original Message----- > From: Jan Christoffersson (EAB) > Sent: den 6 juni 2003 08:43 > To: 'zhigang.c.liu@nokia.com'; richard.price@roke.co.uk; > Lajos Zaccomer > (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org > Subject: RE: [rohc] Dynamic update of resources in SigComp > > > Hi Folks, > > As far as I remember, there is only one exception to the rule > that an endpoint must not decrease its resources and that is > if the compressor sets the 'I' bit to 1, then it's ok for the > other endpoint to reduce (or set to zero) the state memory > size. Apart from this, an endpoint should never decrease its > resources. > As Zhigang says, reducing the available recources on the fly > would make life much more complicated and this was the reason > why the idea was that they should only be increased and never > decreased! > > However, looking through RFC 3320 I cannot find that this is > very clearly written. In section 3.3 it says: > "Each parameter has a minimum value that MUST be offered by all > receiving SigComp endpoints. Moreover, endpoints MAY offer > additional resources if available; these resources can be > advertised > to remote endpoints using the SigComp feedback mechanism." > > Unfortunately, to me this is not clear enough. I agree with > Zhigang that this should be made clearer. Perhaps this is > something for the Implementors Guide to begin with? > > Regards, > Jan > > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 5 juni 2003 19:04 > To: richard.price@roke.co.uk; Lajos Zaccomer (ETH); > Paulius.Meskauskas@nokia.com; rohc@ietf.org > Subject: RE: [rohc] Dynamic update of resources in SigComp > > > Richard, > > > This was true for an early version of SigComp, but we remembered > > to fix it before publishing the final RFC ;-) > > I also remember we had discussion whether to allow reducing resource > dynamically. Decreasing seemed trickier than increasing. So, at one > time, we disallowed it. But I cannot recall details how we reversed > it later? In particular, I couldn't find text in RFC 3320 on this, > or perhaps I missed it? > > > True synchronisation is always impossible over an unreliable > > transport, but the SigComp Feedback mechanism is designed to > > ensure that this isn't a problem. It works much like R-mode of > > RFC 3095, using the following general rule: > > > > "Don't assume that any data has arrived until you get an > > explicit acknowledgement." > > > > So, for example, a compressor should not attempt to access a state > > item unless it receives an explicit acknowledgment that the state > > has been created by the remote endpoint. > > Right. But when an endpoint reduces its SMS, even previously > acknowledged > state(s) may have to be deleted. Then the order of deletion > is important > to maintain synchronization. Presumably, > state_retention_priority should > be used for this purpose (i.e. lowest priority should be > deleted first). > But again, it this clear form RFC 3320? It only takes one or > two sentences > to clarify. > > BR, > Zhigang > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 04:31:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13992 for ; Fri, 6 Jun 2003 04:31:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h568VVA02281 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 04:31:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568VVB02278 for ; Fri, 6 Jun 2003 04:31:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13986 for ; Fri, 6 Jun 2003 04:31:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCbP-0007Mw-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 04:29:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OCbP-0007Mt-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 04:29:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568V2B02231; Fri, 6 Jun 2003 04:31:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568UdB02146 for ; Fri, 6 Jun 2003 04:30:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13921 for ; Fri, 6 Jun 2003 04:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCaZ-0007Lv-00 for rohc@ietf.org; Fri, 06 Jun 2003 04:28:43 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OCaZ-0007Ls-00 for rohc@ietf.org; Fri, 06 Jun 2003 04:28:43 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h568VGbj016243; Fri, 6 Jun 2003 10:31:16 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Jun 2003 10:31:42 +0200 Message-ID: From: "Lajos Zaccomer (ETH)" To: "Jan Christoffersson (EAB)" , "'zhigang.c.liu@nokia.com'" , richard.price@roke.co.uk, Paulius.Meskauskas@nokia.com, rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 10:29:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h568UdB02147 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h568V2B02231 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h568VVB02278 Content-Transfer-Encoding: 8bit Hi, This is the bit that someone called Stupid bit in SIPit. I found it felicity. I forecast that nobody will use this feature, because it requires additional logic in the bytecode, which of course makes it larger (as we know the difference is actually doubled regarding the UMS), and the ultimate goal when developing bytecodes is to make it very short. If the user was punished in some way when it had neither used nor released its allocated resources after a while, it could be a successful scheme to force using the S bit. We should not count on understanding competitors when using each other's resources. If it was expected, you could throw away all security aspects as well. BR/Zacco -----Original Message----- From: Jan Christoffersson (EAB) Sent: 2003. június 6. 9:58 To: Jan Christoffersson (EAB); 'zhigang.c.liu@nokia.com'; richard.price@roke.co.uk; Lajos Zaccomer (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Correction: it should be the 'S' bit, not the 'I' bit in my reply below :-) /Jan -----Original Message----- From: Jan Christoffersson (EAB) Sent: den 6 juni 2003 08:43 To: 'zhigang.c.liu@nokia.com'; richard.price@roke.co.uk; Lajos Zaccomer (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Hi Folks, As far as I remember, there is only one exception to the rule that an endpoint must not decrease its resources and that is if the compressor sets the 'I' bit to 1, then it's ok for the other endpoint to reduce (or set to zero) the state memory size. Apart from this, an endpoint should never decrease its resources. As Zhigang says, reducing the available recources on the fly would make life much more complicated and this was the reason why the idea was that they should only be increased and never decreased! However, looking through RFC 3320 I cannot find that this is very clearly written. In section 3.3 it says: "Each parameter has a minimum value that MUST be offered by all receiving SigComp endpoints. Moreover, endpoints MAY offer additional resources if available; these resources can be advertised to remote endpoints using the SigComp feedback mechanism." Unfortunately, to me this is not clear enough. I agree with Zhigang that this should be made clearer. Perhaps this is something for the Implementors Guide to begin with? Regards, Jan -----Original Message----- From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] Sent: den 5 juni 2003 19:04 To: richard.price@roke.co.uk; Lajos Zaccomer (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Richard, > This was true for an early version of SigComp, but we remembered > to fix it before publishing the final RFC ;-) I also remember we had discussion whether to allow reducing resource dynamically. Decreasing seemed trickier than increasing. So, at one time, we disallowed it. But I cannot recall details how we reversed it later? In particular, I couldn't find text in RFC 3320 on this, or perhaps I missed it? > True synchronisation is always impossible over an unreliable > transport, but the SigComp Feedback mechanism is designed to > ensure that this isn't a problem. It works much like R-mode of > RFC 3095, using the following general rule: > > "Don't assume that any data has arrived until you get an > explicit acknowledgement." > > So, for example, a compressor should not attempt to access a state > item unless it receives an explicit acknowledgment that the state > has been created by the remote endpoint. Right. But when an endpoint reduces its SMS, even previously acknowledged state(s) may have to be deleted. Then the order of deletion is important to maintain synchronization. Presumably, state_retention_priority should be used for this purpose (i.e. lowest priority should be deleted first). But again, it this clear form RFC 3320? It only takes one or two sentences to clarify. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 05:25:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15061 for ; Fri, 6 Jun 2003 05:25:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h569P2P06246 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 05:25:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569P2B06243 for ; Fri, 6 Jun 2003 05:25:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15044 for ; Fri, 6 Jun 2003 05:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODRA-0007gR-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 05:23:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ODRA-0007gO-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 05:23:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569OSB06200; Fri, 6 Jun 2003 05:24:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569NnB06170 for ; Fri, 6 Jun 2003 05:23:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15006 for ; Fri, 6 Jun 2003 05:23:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODQ0-0007g0-00 for rohc@ietf.org; Fri, 06 Jun 2003 05:21:52 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19ODPz-0007fw-00 for rohc@ietf.org; Fri, 06 Jun 2003 05:21:51 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 10:23:14 +0100 Message-ID: From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 10:23:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > > > A.1: Why didn't we define a flag for marking Traffic Class > > > > as replicable? Is this because adding a bit would mean > > > > adding a byte and that would exactly be the saving in the > > > > Traffic class case? > > > > > > GP: > > > This can be added without requiring another octet. We could > > > use codes insteads of flags. As Richard pointed out, we could > > > also add hop limit as well. I can update that. > > Just because it can be done does not mean it should be done. I > personally think we should limit the replication possibilities > to addresses (potentially including ports), as I think it would > be a mistake to make this mechanism too flexible and complex. Hi, It's worth remembering that if we limit the replication possibilities to addresses, then we'll be unable to support more general mechanisms such as Early Compression. Moreover, I think it would be a mistake to assume that more flexible packet formats are necessarily more complex. If you define the packet formats using ROHC-FN, the set which I proposed is actually somewhat easier to describe than Ghyslain's proposal (because it is generated directly from the behaviour of TCP/IP). So we get the extra efficiency and flexibility, without making the profile any more complex. Regards, Richard > > As a comparison, here's a set of IR-REPLICATE packet formats > > for TCP/IP, using indicator codes rather than flags: > > > > http://sigcomp.srmr.co.uk/~rjp/IR_REPLICATE.txt > > I know these are a little bit lengthy, but I would prefer to > still get these to the list. At this point, we do not need to > have many formats, discussions would rather benefit from > having small sets to look at and discuss. Here they are ... Key: "|" indicates the beginning/end of a field. ":" indicates that a field is split over multiple octets. Abbreviations: A = TCP_ACK_FLAG B = TCP_ECN_BITS E = IP_ECN_BITS D = PADDING P = TCP_PSH_FLAG I = IP_DONT_FRAGMENT TEB = TCP_ECN_BITS TRF = TCP_RSF_FLAGS MSN = MASTER_SEQ_NUMBER T = TCP_URG_FLAG IEB = IP_ECN_BITS Packet 0: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 0 | MSN | T | : +---+---+---+---+---+---+---+---+ : TRF | P | A | TEB | IEB | +---+---+---+---+---+---+---+---+ | I | IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 1: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 1 0 | MSN | T | +---+---+---+---+---+---+---+---+ | TRF | P | A | TEB | E : +---+---+---+---+---+---+---+---+ : | I | IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 2: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 1 1 | MSN | T | +---+---+---+---+---+---+---+---+ | TRF | P | A | TEB | E : +---+---+---+---+---+---+---+---+ : | I | IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 3: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 0 0 | MSN | +---+---+---+---+---+---+---+---+ | T | TRF | P | A | TEB | +---+---+---+---+---+---+---+---+ | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 4: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 0 1 | MSN | +---+---+---+---+---+---+---+---+ | T | TRF | P | A | TEB | +---+---+---+---+---+---+---+---+ | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 5: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 0 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 6: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 0 1 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | PADDING | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 7: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 1 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 8: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 1 1 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 9: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 10: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 1 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | +---+---+---+---+---+---+---+---+ | TEB | IEB | I | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 11: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 1 1 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | +---+---+---+---+---+---+---+---+ | TEB | IEB | I | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 12: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 0 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 13: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 0 1 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 14: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 1 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 15: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 1 1 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 16: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 0 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 17: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 0 1 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 18: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 19: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 0 | +---+---+---+---+---+---+---+---+ | MSN | T | TRF | +---+---+---+---+---+---+---+---+ | P | A | TEB | IEB | I | : +---+---+---+---+---+---+---+---+ : IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 20: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ | MSN | T | TRF | +---+---+---+---+---+---+---+---+ | P | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 21: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | : +---+---+---+---+---+---+---+---+ : IP_TOS | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : MASTER_SEQ_NUMBER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_URG_POINTER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_ID | +---+---+---+---+---+---+---+---+ | TCP_OPTIONS_PRESENCE | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_OPTIONS_ORDER : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_DEST_ADDRESS : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_SOURCE_ADDRESS : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 07:02:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17503 for ; Fri, 6 Jun 2003 07:02:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56B2FY12450 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 07:02:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56B2FB12447 for ; Fri, 6 Jun 2003 07:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17466 for ; Fri, 6 Jun 2003 07:02:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OExE-0000a3-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 07:00:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OExD-0000a0-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 07:00:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56B1aB12394; Fri, 6 Jun 2003 07:01:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56AwEB12214 for ; Fri, 6 Jun 2003 06:58:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17214 for ; Fri, 6 Jun 2003 06:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEtK-0000WU-00 for rohc@ietf.org; Fri, 06 Jun 2003 06:56:14 -0400 Received: from mail-jpn.microsoft.com ([207.46.71.29]) by ietf-mx with esmtp (Exim 4.12) id 19OEtJ-0000Vu-00 for rohc@ietf.org; Fri, 06 Jun 2003 06:56:13 -0400 Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 19:57:31 +0900 Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jun 2003 19:57:31 +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.5329); Fri, 6 Jun 2003 19:57:31 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 18:57:29 +0800 Message-ID: Thread-Topic: [rohc] ROHC-TCP: Update and some topics to be discussed Thread-Index: AcMsDaVJmXsnfb2tSWKPEBjGkWdGTQADImFA From: "Hongbin Liao \(Intl Staffing\)" To: "Price, Richard" , "Lars-Erik Jonsson \(EAB\)" , X-OriginalArrivalTime: 06 Jun 2003 10:57:31.0048 (UTC) FILETIME=[6D447280:01C32C1A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56AwEB12215 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Richard Could u give the ``formal notation'' for IR-REPLICATE? It is not clear how that code points are generated? Regards Hongbin 06/06/2003 > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Friday, June 06, 2003 5:23 PM > To: 'Lars-Erik Jonsson (EAB)'; rohc@ietf.org > Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed > > > > > > > A.1: Why didn't we define a flag for marking Traffic Class as > > > > > replicable? Is this because adding a bit would mean adding a > > > > > byte and that would exactly be the saving in the > Traffic class > > > > > case? > > > > > > > > GP: > > > > This can be added without requiring another octet. We could use > > > > codes insteads of flags. As Richard pointed out, we > could also add > > > > hop limit as well. I can update that. > > > > Just because it can be done does not mean it should be done. I > > personally think we should limit the replication possibilities to > > addresses (potentially including ports), as I think it would be a > > mistake to make this mechanism too flexible and complex. > > Hi, > > It's worth remembering that if we limit the replication > possibilities to addresses, then we'll be unable to support > more general mechanisms such as Early Compression. > > Moreover, I think it would be a mistake to assume that more > flexible packet formats are necessarily more complex. If you > define the packet formats using ROHC-FN, the set which I > proposed is actually somewhat easier to describe than > Ghyslain's proposal (because it is generated directly from > the behaviour of TCP/IP). So we get the extra efficiency and > flexibility, without making the profile any more complex. > > Regards, > > Richard > > > > As a comparison, here's a set of IR-REPLICATE packet formats > > > for TCP/IP, using indicator codes rather than flags: > > > > > > http://sigcomp.srmr.co.uk/~rjp/IR_REPLICATE.txt > > > > I know these are a little bit lengthy, but I would prefer > to still get > > these to the list. At this point, we do not need to have > many formats, > > discussions would rather benefit from having small sets to > look at and > > discuss. > > Here they are ... > > Key: > > "|" indicates the beginning/end of a field. > > ":" indicates that a field is split over multiple octets. > > Abbreviations: > > A = TCP_ACK_FLAG > B = TCP_ECN_BITS > E = IP_ECN_BITS > D = PADDING > P = TCP_PSH_FLAG > I = IP_DONT_FRAGMENT > TEB = TCP_ECN_BITS > TRF = TCP_RSF_FLAGS > MSN = MASTER_SEQ_NUMBER > T = TCP_URG_FLAG > IEB = IP_ECN_BITS > > Packet 0: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 0 0 | MSN | T | : > +---+---+---+---+---+---+---+---+ > : TRF | P | A | TEB | IEB | > +---+---+---+---+---+---+---+---+ > | I | IP_ID | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 1: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 0 1 0 | MSN | T | > +---+---+---+---+---+---+---+---+ > | TRF | P | A | TEB | E : > +---+---+---+---+---+---+---+---+ > : | I | IP_ID | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 2: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 0 1 1 | MSN | T | > +---+---+---+---+---+---+---+---+ > | TRF | P | A | TEB | E : > +---+---+---+---+---+---+---+---+ > : | I | IP_ID | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 3: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 0 0 0 | MSN | > +---+---+---+---+---+---+---+---+ > | T | TRF | P | A | TEB | > +---+---+---+---+---+---+---+---+ > | IEB | I | IP_ID | D | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 4: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 0 0 1 | MSN | > +---+---+---+---+---+---+---+---+ > | T | TRF | P | A | TEB | > +---+---+---+---+---+---+---+---+ > | IEB | I | IP_ID | D | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 5: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 0 1 0 0 | MSN : > +---+---+---+---+---+---+---+---+ > : | T | TRF | P | A | B : > +---+---+---+---+---+---+---+---+ > : | IEB | I | IP_ID | D | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 6: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 0 1 0 1 | MSN : > +---+---+---+---+---+---+---+---+ > : | T | TRF | P | A | B : > +---+---+---+---+---+---+---+---+ > : | IEB | I | PADDING | > +---+---+---+---+---+---+---+---+ > | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 7: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 0 1 1 0 | MSN : > +---+---+---+---+---+---+---+---+ > : | T | TRF | P | A | B : > +---+---+---+---+---+---+---+---+ > : | IEB | I | IP_ID | D | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 8: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 0 1 1 1 | MSN : > +---+---+---+---+---+---+---+---+ > : | T | TRF | P | A | B : > +---+---+---+---+---+---+---+---+ > : | IEB | I | IP_ID | D | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 9: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 0 0 | MSN : > +---+---+---+---+---+---+---+---+ > : | T | TRF | P | A | B : > +---+---+---+---+---+---+---+---+ > : | IEB | I | IP_ID | D | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 10: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 0 1 0 | MSN : > +---+---+---+---+---+---+---+---+ > : | T | TRF | P | A | > +---+---+---+---+---+---+---+---+ > | TEB | IEB | I | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 11: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 0 1 1 | MSN : > +---+---+---+---+---+---+---+---+ > : | T | TRF | P | A | > +---+---+---+---+---+---+---+---+ > | TEB | IEB | I | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 12: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 0 0 0 | : > +---+---+---+---+---+---+---+---+ > : MSN | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | D | > +---+---+---+---+---+---+---+---+ > | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 13: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 0 0 1 | : > +---+---+---+---+---+---+---+---+ > : MSN | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | D | > +---+---+---+---+---+---+---+---+ > | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 14: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 0 1 0 | : > +---+---+---+---+---+---+---+---+ > : MSN | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | IP_ID : > +---+---+---+---+---+---+---+---+ > : | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 15: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 0 1 1 | : > +---+---+---+---+---+---+---+---+ > : MSN | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | IP_ID : > +---+---+---+---+---+---+---+---+ > : | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 16: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 1 0 0 | : > +---+---+---+---+---+---+---+---+ > : MSN | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | D | > +---+---+---+---+---+---+---+---+ > | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 17: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 1 0 1 | : > +---+---+---+---+---+---+---+---+ > : MSN | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | D | > +---+---+---+---+---+---+---+---+ > | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 18: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 1 1 0 | : > +---+---+---+---+---+---+---+---+ > : MSN | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | IP_ID : > +---+---+---+---+---+---+---+---+ > : | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 19: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 1 1 1 0 | > +---+---+---+---+---+---+---+---+ > | MSN | T | TRF | > +---+---+---+---+---+---+---+---+ > | P | A | TEB | IEB | I | : > +---+---+---+---+---+---+---+---+ > : IP_ID | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > > Packet 20: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 0 1 1 1 1 1 | > +---+---+---+---+---+---+---+---+ > | MSN | T | TRF | > +---+---+---+---+---+---+---+---+ > | P | A | TEB | IEB | I | D | > +---+---+---+---+---+---+---+---+ > | IP_ID | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > > Packet 21: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 1 | T | TRF | P | > +---+---+---+---+---+---+---+---+ > | A | TEB | IEB | I | : > +---+---+---+---+---+---+---+---+ > : IP_TOS | PADDING | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : MASTER_SEQ_NUMBER | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_URG_POINTER | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_WINDOW | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : IP_ID | > +---+---+---+---+---+---+---+---+ > | TCP_OPTIONS_PRESENCE | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_OPTIONS_ORDER : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_ACK_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SEQ_NUMBER : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_DEST_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_SOURCE_PORT | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : TCP_CHECKSUM | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : IP_DEST_ADDRESS : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | : > +---+---+---+---+---+---+---+---+ > : IP_SOURCE_ADDRESS : > +---+---+---+---+---+---+---+---+ > : ... : > +---+---+---+---+---+---+---+---+ > : ... | > +---+---+---+---+---+---+---+---+ > | IP_TIME_TO_LIVE | > +---+---+---+---+---+---+---+---+ > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 07:24:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18060 for ; Fri, 6 Jun 2003 07:24:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56BNlB14190 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 07:23:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56BNlB14187 for ; Fri, 6 Jun 2003 07:23:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18037 for ; Fri, 6 Jun 2003 07:23:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OFI8-0000kF-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 07:21:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OFI7-0000kC-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 07:21:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56BNCB14157; Fri, 6 Jun 2003 07:23:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56BMxB14124 for ; Fri, 6 Jun 2003 07:22:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18022 for ; Fri, 6 Jun 2003 07:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OFHM-0000jj-00 for rohc@ietf.org; Fri, 06 Jun 2003 07:21:04 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19OFHL-0000jY-00 for rohc@ietf.org; Fri, 06 Jun 2003 07:21:03 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 12:22:26 +0100 Message-ID: From: "Price, Richard" To: "'Hongbin Liao (Intl Staffing)'" , "Lars-Erik Jonsson (EAB)" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 12:22:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Hongbin, I've attached the ROHC-FN description of the IR-REPLICATE packet formats. It's almost identical to the description of the CO packet formats, with a couple of tweaks - I've deleted some encodings that are useful in the CO packets, but probably won't be needed for IR-REPLICATE packets. Regards, Richard --------------------------------------------------------- ir_replicate_formats ::= ordinary_huffman(tcp_ip_header) tcp_ip_header ::= create_msn ip_header tcp_header master_seq_number ip_header ::= inferred_ip_checksum inferred_size(16,-16) ip_version ip_header_length ip_tos ip_length ip_id ip_reserved ip_dont_fragment ip_more_fragments ip_offset ip_time_to_live ip_protocol ip_checksum ip_source_address ip_dest_address tcp_header ::= tcp_checksum tcp_source_port tcp_dest_port tcp_seq_number tcp_ack_number tcp_data_offset tcp_reserved tcp_ip_ecn_fields tcp_urg tcp_ack_flag tcp_psh_flag tcp_rsf_flags tcp_window tcp_urg_fields master_seq_number ::= next_field(msn) lsb(4,0) // irregular(16) ip_version ::= value(4,4) ip_header_length ::= value(4,5) ip_tos ::= static // irregular(6) label(2,ecn) ip_length ::= skip(16) ip_id ::= inferred_offset(16,msn) lsb(3,0) 90% / lsb(8,0) 10% // irregular(16) ip_reserved ::= value(1,0) ip_dont_fragment ::= irregular(1) ip_more_fragments ::= value(1,0) ip_offset ::= value(13,0) ip_time_to_live ::= static 80% / irregular(8) 20% ip_protocol ::= value(8,6) ip_checksum ::= skip(16) ip_source_address ::= static // irregular(32) ip_dest_address ::= static // irregular(32) tcp_source_port ::= static 70% / lsb(8,0) 30% // irregular(16) tcp_dest_port ::= static 70% / lsb(8,0) 30% // irregular(16) tcp_seq_number ::= irregular(32) tcp_ack_number ::= value(32,0) 80% / irregular(32) 20% tcp_data_offset ::= label(4,data_offset) tcp_reserved ::= value(4,0) tcp_ip_ecn_fields ::= next_field(ecn) ip_ecn_bits tcp_ecn_bits ip_ecn_bits ::= irregular(2) tcp_ecn_bits ::= irregular(2) tcp_urg ::= label(1,urg_flag) tcp_ack_flag ::= irregular(1) tcp_psh_flag ::= irregular(1) tcp_rsf_flags ::= irregular(3) tcp_window ::= static // irregular(16) skip(16) tcp_checksum ::= irregular(16) tcp_urg_fields ::= next_field(urg_flag) urgf_zero // urgf_one urgf_zero ::= tcp_urg_flag static urgf_one ::= tcp_urg_flag tcp_urg_pointer tcp_urg_flag ::= irregular(1) tcp_urg_pointer ::= irregular(16) > -----Original Message----- > From: Hongbin Liao (Intl Staffing) [mailto:i-hbliao@microsoft.com] > Sent: Friday, June 06, 2003 11:57 AM > To: Price, Richard; Lars-Erik Jonsson (EAB); rohc@ietf.org > Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed > > > Hi, Richard > Could u give the ``formal notation'' for IR-REPLICATE? > It is not clear how that code points are generated? > > Regards > Hongbin > 06/06/2003 > > > -----Original Message----- > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Friday, June 06, 2003 5:23 PM > > To: 'Lars-Erik Jonsson (EAB)'; rohc@ietf.org > > Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed > > > > > > > > > > A.1: Why didn't we define a flag for marking Traffic Class as > > > > > > replicable? Is this because adding a bit would mean adding a > > > > > > byte and that would exactly be the saving in the Traffic class > > > > > > case? > > > > > > > > > > GP: > > > > > This can be added without requiring another octet. We could use > > > > > codes insteads of flags. As Richard pointed out, we could also add > > > > > hop limit as well. I can update that. > > > > > > Just because it can be done does not mean it should be done. I > > > personally think we should limit the replication possibilities to > > > addresses (potentially including ports), as I think it would be a > > > mistake to make this mechanism too flexible and complex. > > > > Hi, > > > > It's worth remembering that if we limit the replication > > possibilities to addresses, then we'll be unable to support > > more general mechanisms such as Early Compression. > > > > Moreover, I think it would be a mistake to assume that more > > flexible packet formats are necessarily more complex. If you > > define the packet formats using ROHC-FN, the set which I > > proposed is actually somewhat easier to describe than > > Ghyslain's proposal (because it is generated directly from > > the behaviour of TCP/IP). So we get the extra efficiency and > > flexibility, without making the profile any more complex. > > > > Regards, > > > > Richard > > > > > > As a comparison, here's a set of IR-REPLICATE packet formats > > > > for TCP/IP, using indicator codes rather than flags: > > > > > > > > http://sigcomp.srmr.co.uk/~rjp/IR_REPLICATE.txt > > > > > > I know these are a little bit lengthy, but I would prefer to still get > > > these to the list. At this point, we do not need to have many formats, > > > discussions would rather benefit from having small sets to look at and > > > discuss. > > > > Here they are ... > > > > Key: > > > > "|" indicates the beginning/end of a field. > > > > ":" indicates that a field is split over multiple octets. > > > > Abbreviations: > > > > A = TCP_ACK_FLAG > > B = TCP_ECN_BITS > > E = IP_ECN_BITS > > D = PADDING > > P = TCP_PSH_FLAG > > I = IP_DONT_FRAGMENT > > TEB = TCP_ECN_BITS > > TRF = TCP_RSF_FLAGS > > MSN = MASTER_SEQ_NUMBER > > T = TCP_URG_FLAG > > IEB = IP_ECN_BITS > > > > Packet 0: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 0 0 | MSN | T | : > > +---+---+---+---+---+---+---+---+ > > : TRF | P | A | TEB | IEB | > > +---+---+---+---+---+---+---+---+ > > | I | IP_ID | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 1: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 0 1 0 | MSN | T | > > +---+---+---+---+---+---+---+---+ > > | TRF | P | A | TEB | E : > > +---+---+---+---+---+---+---+---+ > > : | I | IP_ID | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 2: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 0 1 1 | MSN | T | > > +---+---+---+---+---+---+---+---+ > > | TRF | P | A | TEB | E : > > +---+---+---+---+---+---+---+---+ > > : | I | IP_ID | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 3: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 0 0 0 | MSN | > > +---+---+---+---+---+---+---+---+ > > | T | TRF | P | A | TEB | > > +---+---+---+---+---+---+---+---+ > > | IEB | I | IP_ID | D | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 4: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 0 0 1 | MSN | > > +---+---+---+---+---+---+---+---+ > > | T | TRF | P | A | TEB | > > +---+---+---+---+---+---+---+---+ > > | IEB | I | IP_ID | D | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 5: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 0 1 0 0 | MSN : > > +---+---+---+---+---+---+---+---+ > > : | T | TRF | P | A | B : > > +---+---+---+---+---+---+---+---+ > > : | IEB | I | IP_ID | D | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 6: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 0 1 0 1 | MSN : > > +---+---+---+---+---+---+---+---+ > > : | T | TRF | P | A | B : > > +---+---+---+---+---+---+---+---+ > > : | IEB | I | PADDING | > > +---+---+---+---+---+---+---+---+ > > | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 7: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 0 1 1 0 | MSN : > > +---+---+---+---+---+---+---+---+ > > : | T | TRF | P | A | B : > > +---+---+---+---+---+---+---+---+ > > : | IEB | I | IP_ID | D | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 8: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 0 1 1 1 | MSN : > > +---+---+---+---+---+---+---+---+ > > : | T | TRF | P | A | B : > > +---+---+---+---+---+---+---+---+ > > : | IEB | I | IP_ID | D | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 9: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 0 0 | MSN : > > +---+---+---+---+---+---+---+---+ > > : | T | TRF | P | A | B : > > +---+---+---+---+---+---+---+---+ > > : | IEB | I | IP_ID | D | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 10: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 0 1 0 | MSN : > > +---+---+---+---+---+---+---+---+ > > : | T | TRF | P | A | > > +---+---+---+---+---+---+---+---+ > > | TEB | IEB | I | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 11: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 0 1 1 | MSN : > > +---+---+---+---+---+---+---+---+ > > : | T | TRF | P | A | > > +---+---+---+---+---+---+---+---+ > > | TEB | IEB | I | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 12: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 0 0 0 | : > > +---+---+---+---+---+---+---+---+ > > : MSN | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | D | > > +---+---+---+---+---+---+---+---+ > > | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 13: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 0 0 1 | : > > +---+---+---+---+---+---+---+---+ > > : MSN | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | D | > > +---+---+---+---+---+---+---+---+ > > | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 14: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 0 1 0 | : > > +---+---+---+---+---+---+---+---+ > > : MSN | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | IP_ID : > > +---+---+---+---+---+---+---+---+ > > : | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 15: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 0 1 1 | : > > +---+---+---+---+---+---+---+---+ > > : MSN | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | IP_ID : > > +---+---+---+---+---+---+---+---+ > > : | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 16: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 1 0 0 | : > > +---+---+---+---+---+---+---+---+ > > : MSN | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | D | > > +---+---+---+---+---+---+---+---+ > > | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 17: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 1 0 1 | : > > +---+---+---+---+---+---+---+---+ > > : MSN | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | D | > > +---+---+---+---+---+---+---+---+ > > | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 18: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 1 1 0 | : > > +---+---+---+---+---+---+---+---+ > > : MSN | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | IP_ID : > > +---+---+---+---+---+---+---+---+ > > : | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 19: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 1 1 1 0 | > > +---+---+---+---+---+---+---+---+ > > | MSN | T | TRF | > > +---+---+---+---+---+---+---+---+ > > | P | A | TEB | IEB | I | : > > +---+---+---+---+---+---+---+---+ > > : IP_ID | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > > > Packet 20: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 0 1 1 1 1 1 | > > +---+---+---+---+---+---+---+---+ > > | MSN | T | TRF | > > +---+---+---+---+---+---+---+---+ > > | P | A | TEB | IEB | I | D | > > +---+---+---+---+---+---+---+---+ > > | IP_ID | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > > > Packet 21: > > > > 0 1 2 3 4 5 6 7 > > +---+---+---+---+---+---+---+---+ > > | 1 1 1 | T | TRF | P | > > +---+---+---+---+---+---+---+---+ > > | A | TEB | IEB | I | : > > +---+---+---+---+---+---+---+---+ > > : IP_TOS | PADDING | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : MASTER_SEQ_NUMBER | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_URG_POINTER | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_WINDOW | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : IP_ID | > > +---+---+---+---+---+---+---+---+ > > | TCP_OPTIONS_PRESENCE | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_OPTIONS_ORDER : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_ACK_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SEQ_NUMBER : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_DEST_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_SOURCE_PORT | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : TCP_CHECKSUM | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : IP_DEST_ADDRESS : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | : > > +---+---+---+---+---+---+---+---+ > > : IP_SOURCE_ADDRESS : > > +---+---+---+---+---+---+---+---+ > > : ... : > > +---+---+---+---+---+---+---+---+ > > : ... | > > +---+---+---+---+---+---+---+---+ > > | IP_TIME_TO_LIVE | > > +---+---+---+---+---+---+---+---+ > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 07:42:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18390 for ; Fri, 6 Jun 2003 07:42:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56BfhW15894 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 07:41:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56BfgB15891 for ; Fri, 6 Jun 2003 07:41:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18383 for ; Fri, 6 Jun 2003 07:41:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OFZT-0000qx-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 07:39:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OFZT-0000qu-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 07:39:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56BfHB15863; Fri, 6 Jun 2003 07:41:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56BeHB15830 for ; Fri, 6 Jun 2003 07:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18362 for ; Fri, 6 Jun 2003 07:40:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OFY6-0000q0-00 for rohc@ietf.org; Fri, 06 Jun 2003 07:38:22 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19OFY6-0000px-00 for rohc@ietf.org; Fri, 06 Jun 2003 07:38:22 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 12:39:45 +0100 Message-ID: From: "Price, Richard" To: "'Lajos Zaccomer (ETH)'" Cc: "'Paulius.Meskauskas@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 12:39:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > This was true for an early version of SigComp, but we remembered > to fix it before publishing the final RFC ;-) > > >> Where is this specified in the RFC? Hi Zacco, The following is specified in Section 9.4.9 of RFC 3320: Moreover, the responsibility for ensuring that feedback data arrives successfully over an unreliable transport lies with the sender. The receiving endpoint always uses the last received value for each field in the feedback data, even if the values are out of date due to packet loss or misordering. So, if the receiving endpoint is told by the feedback data that the amount of available resources has been reduced, it must ensure that it doesn't use the resources any more (otherwise decompression failure might occur). > An endpoint can now choose to reduce the amount of resources that > it offers on-the-fly, provided that it does so in a robust manner > (i.e. it needs to make sure that the remote endpoint knows that > the available resources have been reduced, before it actually > reclaims them). > > One possible way to keep the endpoints in sync is to use the > SigComp Feedback mechanism. In this case, the following two steps > need to be taken: > > 1. The endpoint sends a message announcing the reduced resources, > (but does not make the actual reductions just yet). It also > requests an acknowledgement of the message to be returned via > the SigComp Feedback mechanism. > > 2. When the acknowledgement is returned, the endpoint knows that > the original message has been successfully received. It can then > safely reclaim the resources without causing decompression > failures to occur. > > > As you cannot force another endpoint to send its parameters, > > true synchronization is impossible > > True synchronisation is always impossible over an unreliable > transport, but the SigComp Feedback mechanism is designed to > ensure that this isn't a problem. It works much like R-mode of > RFC 3095, using the following general rule: > > "Don't assume that any data has arrived until you get an > explicit acknowledgement." > > >> I didn't mean the unreliable layer. I meant that I cannot > ask an another endpoint to send its parameters, as this > activity is only a SHOULD, thus we cannot rely on this. This is exactly how things should be, since it would be a very bad idea to implement an endpoint which crashed every time the remote endpoint failed to return a feedback message! Note that even if we made returning the feedback a MUST, it would still be possible for the message to be lost or corrupted while travelling between the two endpoints. > So, for example, a compressor should not attempt to access a state > item unless it receives an explicit acknowledgment that the state > has been created by the remote endpoint. > > >> Having the ack does not mean that the state was > successfully saved. It means that the sigcomp message was > successfully decompressed and the application autenticated > it. We have no information if the state was indeed saved. We can guarantee that a state item has been saved if we know two things: 1. The message which created the state was successfully received, decompressed and authenticated. 2. Enough state memory was available to save the state. We know that 1.) is true by receiving the ACK in the first place. We know that 2.) is true by reading the state_memory_size parameter in the feedback, and making sure that it is large enough. So the feedback data contains all the information we need to guarantee that the state was successfully saved. > > (lack of signalling - NACK was partly introduced to eliminate > > this shortcoming). > > The volume of signalling traffic is under the control of the > compressor. If it wishes, it can use the SigComp Feedback > mechanism to request the explicit acknowledgement of every single > compressed message. > > >> I think that it was rather misleading to call the normal > feedback remote compressor initiated explicit > acknowledgement, as it is described in RFC 3321 as something > new. But this is not the point. The normal feedback (or > remote compressor initiated explicit acknowledgement) has the > above detailed shortcoming. I think that the feedback mechanism works fine (i.e. provides a guarantee that state was saved), provided that you check the state_memory_size parameter to make sure that the state wasn't rejected due to insufficient memory. > While the local endpoint initiated explicit acknowledgement has > another shortcoming: there may be up to four state creates and > only one of them can be explicitely acked. But unfortunately we > don't know which one, as you said it was an implementation decision. > In consequence, this is not reliable, too. Local endpoint initiated acks can acknowledge more than one state item (see Figure 13 of RFC 3320 - there is room for an arbitrary number of state identifiers). > The NACK mechanism can help endpoints to recover if they lose > synchronisation - however, the SigComp Feedback mechanism is > designed to prevent this from occurring in the first place! > > > If a compartment is out of synchron, the only thing it can do > > is to fall back to the initial state, just as if nothing has > > happened before. > > True. Note however that a pair of correctly implemented SigComp > endpoints will lose synchronisation roughly once in every 2^48 > compressed messages (assuming 6-byte hashes)! So if this happens > regularly, it's a good indication that there's something amiss... > > >> This is theory. In reality, there might be other problems > (e.g. the feedback is sent back, but the sate could not be > saved for the state database is full or for some reason not > accessible, This situation MUST be indicated using the state_memory_size parameter in the returned SigComp parameters. If an endpoint can't save the state for whatever reason (e.g. it's run out of memory), then the state_memory_size MUST be set to 0. This allows the remote endpoint to work out whether or not the state was saved successfully. > or there might be a corrupted message that the > SIP parser accepts but the state will not match) and this > probablity may be considerably higher. Corrupted messages can be detected by a CRC or a hash over the original uncompressed message. As usual with SigComp, the endpoint which sent the message is free to choose how much protection it wishes to provide against corrupt messages. For example, if we use a 6-byte hash to protect the message then only 1 in 2^48 corrupt messages will fail to be detected. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 08:16:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19168 for ; Fri, 6 Jun 2003 08:16:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56CFji18112 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 08:15:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CFjB18109 for ; Fri, 6 Jun 2003 08:15:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19164 for ; Fri, 6 Jun 2003 08:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OG6P-0000z7-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:13:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OG6O-0000z4-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:13:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CFJB18098; Fri, 6 Jun 2003 08:15:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CE1B18045 for ; Fri, 6 Jun 2003 08:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19125 for ; Fri, 6 Jun 2003 08:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OG4j-0000yj-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:12:05 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19OG4i-0000yg-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:12:04 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 13:13:28 +0100 Message-ID: From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , Lajos.Zaccomer@eth.ericsson.se, Paulius.Meskauskas@nokia.com, rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 13:13:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > This was true for an early version of SigComp, but we remembered > > to fix it before publishing the final RFC ;-) > > I also remember we had discussion whether to allow reducing resource > dynamically. Decreasing seemed trickier than increasing. So, at one > time, we disallowed it. But I cannot recall details how we reversed > it later? In particular, I couldn't find text in RFC 3320 on this, > or perhaps I missed it? Hi Zhigang, IIRC, we discussed this issue in one of the phone conferences before last-calling the standard. The three main points which we all seemed to agree on were as follows: 1. Reducing the amount of state memory on-the-fly is a Bad Thing! 2. There may be rare cases where an endpoint has no choice but to reduce the state memory (e.g. if it's broken). 3. If 2 occurs, it's better to let the remote endpoint know that the state memory is no longer available than to pretend that everything's still ok. From the above, we decided not to disallow the possibility that an endpoint might have to reduce its offered resources mid-call. Instead, we decided that the receiver should always use the resources offered in the last successfully authenticated feedback data. From RFC 3320: Moreover, the responsibility for ensuring that feedback data arrives successfully over an unreliable transport lies with the sender. The receiving endpoint always uses the last received value for each field in the feedback data, even if the values are out of date due to packet loss or misordering. > > True synchronisation is always impossible over an unreliable > > transport, but the SigComp Feedback mechanism is designed to > > ensure that this isn't a problem. It works much like R-mode of > > RFC 3095, using the following general rule: > > > > "Don't assume that any data has arrived until you get an > > explicit acknowledgement." > > > > So, for example, a compressor should not attempt to access a state > > item unless it receives an explicit acknowledgment that the state > > has been created by the remote endpoint. > > Right. But when an endpoint reduces its SMS, even previously acknowledged > state(s) may have to be deleted. Then the order of deletion is important > to maintain synchronization. Presumably, state_retention_priority should > be used for this purpose (i.e. lowest priority should be deleted first). > But again, it this clear form RFC 3320? It only takes one or two sentences > to clarify. I think that the order in which states are deleted is clear from RFC 3320: The order in which the existing state items are freed is determined by the state_retention_priority, which is set when the state items are created. The state_retention_priority of 65535 is reserved for locally available states; these states must always be freed first. Apart from this special case, states with the lowest state_retention_priority are always freed first. In the event of a tie, then the state item created first in the compartment is also the first to be freed. However, I agree that more clarification of the issue would be useful in general. I think that it would be good to clarify at least the following: * Endpoints SHOULD make every effort to keep a constant amount of resources available for a compartment, as it's awkward to keep adjusting the resources on-the-fly. * If an endpoint really needs to reduce the amount of resources for a compartment, it SHOULD tell the remote endpoint that it has done so (using the SigComp Feedback mechanism). * The remote endpoint MUST use only the resources offered in the last successfully authenticated feedback data, even if this is less than was offered previously. However, since this behaviour is rare, there's no need to worry about getting a good compression ratio any more (e.g. it would be ok for an endpoint just to fall back to stateless compression, rather than worry about which states have been deleted and which are still available). Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 08:34:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19843 for ; Fri, 6 Jun 2003 08:34:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56CXlu18869 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 08:33:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CXlB18866 for ; Fri, 6 Jun 2003 08:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19831 for ; Fri, 6 Jun 2003 08:33:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGNq-0001B5-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:31:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OGNq-0001B2-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:31:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CXBB18847; Fri, 6 Jun 2003 08:33:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CWZB18816 for ; Fri, 6 Jun 2003 08:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19784 for ; Fri, 6 Jun 2003 08:32:32 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGMh-0001AG-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:30:39 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19OGMg-0001AD-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:30:38 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h56CWVb14316 for ; Fri, 6 Jun 2003 07:32:31 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 07:32:30 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 07:31:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 07:31:31 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0121DBDF@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-TCP: Update and some topics to be discussed Thread-Index: AcMsDX8nte+mxlkwS+WKW1nSSx5nXAAGayfg To: , , X-OriginalArrivalTime: 06 Jun 2003 12:31:32.0280 (UTC) FILETIME=[8FB42380:01C32C27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56CWZB18817 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I would also support Richard's thoughts that we should not limit replication to few fields, like addresses and ports. Also, using codes instead of flags is not adding complexity. Regards, Yousuf -----Original Message----- From: ext Price, Richard [mailto:richard.price@roke.co.uk] Sent: Friday, June 06, 2003 4:23 AM To: 'Lars-Erik Jonsson (EAB)'; rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed > > > > A.1: Why didn't we define a flag for marking Traffic Class > > > > as replicable? Is this because adding a bit would mean > > > > adding a byte and that would exactly be the saving in the > > > > Traffic class case? > > > > > > GP: > > > This can be added without requiring another octet. We could > > > use codes insteads of flags. As Richard pointed out, we could > > > also add hop limit as well. I can update that. > > Just because it can be done does not mean it should be done. I > personally think we should limit the replication possibilities > to addresses (potentially including ports), as I think it would > be a mistake to make this mechanism too flexible and complex. Hi, It's worth remembering that if we limit the replication possibilities to addresses, then we'll be unable to support more general mechanisms such as Early Compression. Moreover, I think it would be a mistake to assume that more flexible packet formats are necessarily more complex. If you define the packet formats using ROHC-FN, the set which I proposed is actually somewhat easier to describe than Ghyslain's proposal (because it is generated directly from the behaviour of TCP/IP). So we get the extra efficiency and flexibility, without making the profile any more complex. Regards, Richard > > As a comparison, here's a set of IR-REPLICATE packet formats > > for TCP/IP, using indicator codes rather than flags: > > > > http://sigcomp.srmr.co.uk/~rjp/IR_REPLICATE.txt > > I know these are a little bit lengthy, but I would prefer to > still get these to the list. At this point, we do not need to > have many formats, discussions would rather benefit from > having small sets to look at and discuss. Here they are ... Key: "|" indicates the beginning/end of a field. ":" indicates that a field is split over multiple octets. Abbreviations: A = TCP_ACK_FLAG B = TCP_ECN_BITS E = IP_ECN_BITS D = PADDING P = TCP_PSH_FLAG I = IP_DONT_FRAGMENT TEB = TCP_ECN_BITS TRF = TCP_RSF_FLAGS MSN = MASTER_SEQ_NUMBER T = TCP_URG_FLAG IEB = IP_ECN_BITS Packet 0: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 0 | MSN | T | : +---+---+---+---+---+---+---+---+ : TRF | P | A | TEB | IEB | +---+---+---+---+---+---+---+---+ | I | IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 1: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 1 0 | MSN | T | +---+---+---+---+---+---+---+---+ | TRF | P | A | TEB | E : +---+---+---+---+---+---+---+---+ : | I | IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 2: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 1 1 | MSN | T | +---+---+---+---+---+---+---+---+ | TRF | P | A | TEB | E : +---+---+---+---+---+---+---+---+ : | I | IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 3: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 0 0 | MSN | +---+---+---+---+---+---+---+---+ | T | TRF | P | A | TEB | +---+---+---+---+---+---+---+---+ | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 4: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 0 1 | MSN | +---+---+---+---+---+---+---+---+ | T | TRF | P | A | TEB | +---+---+---+---+---+---+---+---+ | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 5: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 0 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 6: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 0 1 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | PADDING | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 7: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 1 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 8: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 0 1 1 1 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 9: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | B : +---+---+---+---+---+---+---+---+ : | IEB | I | IP_ID | D | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 10: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 1 0 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | +---+---+---+---+---+---+---+---+ | TEB | IEB | I | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 11: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 0 1 1 | MSN : +---+---+---+---+---+---+---+---+ : | T | TRF | P | A | +---+---+---+---+---+---+---+---+ | TEB | IEB | I | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 12: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 0 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 13: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 0 1 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 14: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 1 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 15: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 0 1 1 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 16: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 0 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 17: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 0 1 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 18: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 0 | : +---+---+---+---+---+---+---+---+ : MSN | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | IP_ID : +---+---+---+---+---+---+---+---+ : | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 19: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 0 | +---+---+---+---+---+---+---+---+ | MSN | T | TRF | +---+---+---+---+---+---+---+---+ | P | A | TEB | IEB | I | : +---+---+---+---+---+---+---+---+ : IP_ID | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ Packet 20: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ | MSN | T | TRF | +---+---+---+---+---+---+---+---+ | P | A | TEB | IEB | I | D | +---+---+---+---+---+---+---+---+ | IP_ID | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ Packet 21: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 | T | TRF | P | +---+---+---+---+---+---+---+---+ | A | TEB | IEB | I | : +---+---+---+---+---+---+---+---+ : IP_TOS | PADDING | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : MASTER_SEQ_NUMBER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_URG_POINTER | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_WINDOW | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_ID | +---+---+---+---+---+---+---+---+ | TCP_OPTIONS_PRESENCE | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_OPTIONS_ORDER : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_ACK_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SEQ_NUMBER : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_DEST_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_SOURCE_PORT | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : TCP_CHECKSUM | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_DEST_ADDRESS : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | : +---+---+---+---+---+---+---+---+ : IP_SOURCE_ADDRESS : +---+---+---+---+---+---+---+---+ : ... : +---+---+---+---+---+---+---+---+ : ... | +---+---+---+---+---+---+---+---+ | IP_TIME_TO_LIVE | +---+---+---+---+---+---+---+---+ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 08:42:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20631 for ; Fri, 6 Jun 2003 08:42:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56CfaI20121 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 08:41:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CfaB20118 for ; Fri, 6 Jun 2003 08:41:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20615 for ; Fri, 6 Jun 2003 08:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGVP-0001OW-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:39:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OGVO-0001OT-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:39:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Cf4B20097; Fri, 6 Jun 2003 08:41:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CeHB20069 for ; Fri, 6 Jun 2003 08:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20557 for ; Fri, 6 Jun 2003 08:40:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGU9-0001NA-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:38:21 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19OGU8-0001N7-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:38:20 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 13:40:13 +0100 Message-ID: From: "Price, Richard" To: "'Jan Christoffersson (EAB)'" , "'zhigang.c.liu@nokia.com'" , "Lajos Zaccomer (ETH)" , Paulius.Meskauskas@nokia.com, rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 13:40:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Hi Folks, > > As far as I remember, there is only one exception to the rule > that an endpoint must not decrease its resources and that is > if the compressor sets the 'I' bit to 1, then it's ok for the > other endpoint to reduce (or set to zero) the state memory > size. Apart from this, an endpoint should never decrease its > resources. Hi Jan, I agree that an endpoint SHOULD never decrease the amount of resources which it offers (unless the remote endpoint indicates that the resources are no longer needed). However, if something goes wrong and an endpoint is forced to reduce the available resources for whatever reason, it's much better to do this in a way that prevents decompression failures from occurring. In particular, the SigComp feedback mechanism SHOULD be used to tell the remote endpoint that the resources are no longer available, and the remote endpoint MUST act on this information (e.g. by falling back to stateless compression). > As Zhigang says, reducing the available recources on the fly > would make life much more complicated and this was the reason > why the idea was that they should only be increased and never > decreased! Same applies for increasing the resources on-the-fly as well (this never causes decompression failure, but it's awkward for an endpoint to take advantage of extra resources mid-call, so the majority of endpoints will simply ignore the additional resources altogether). Much better to decide on the amount of available resources when the compartment is established, and to keep them constant for the lifetime of the compartment. > However, looking through RFC 3320 I cannot find that this is > very clearly written. In section 3.3 it says: > "Each parameter has a minimum value that MUST be offered by all > receiving SigComp endpoints. Moreover, endpoints MAY offer > additional resources if available; these resources can be advertised > to remote endpoints using the SigComp feedback mechanism." > > Unfortunately, to me this is not clear enough. I agree with > Zhigang that this should be made clearer. Perhaps this is > something for the Implementors Guide to begin with? Agree completely. Let's add a section to the Implementer's Guide to clarify the situation. Regards, Richard > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 5 juni 2003 19:04 > To: richard.price@roke.co.uk; Lajos Zaccomer (ETH); > Paulius.Meskauskas@nokia.com; rohc@ietf.org > Subject: RE: [rohc] Dynamic update of resources in SigComp > > > Richard, > > > This was true for an early version of SigComp, but we remembered > > to fix it before publishing the final RFC ;-) > > I also remember we had discussion whether to allow reducing resource > dynamically. Decreasing seemed trickier than increasing. So, at one > time, we disallowed it. But I cannot recall details how we reversed > it later? In particular, I couldn't find text in RFC 3320 on this, > or perhaps I missed it? > > > True synchronisation is always impossible over an unreliable > > transport, but the SigComp Feedback mechanism is designed to > > ensure that this isn't a problem. It works much like R-mode of > > RFC 3095, using the following general rule: > > > > "Don't assume that any data has arrived until you get an > > explicit acknowledgement." > > > > So, for example, a compressor should not attempt to access a state > > item unless it receives an explicit acknowledgment that the state > > has been created by the remote endpoint. > > Right. But when an endpoint reduces its SMS, even previously acknowledged > state(s) may have to be deleted. Then the order of deletion is important > to maintain synchronization. Presumably, state_retention_priority should > be used for this purpose (i.e. lowest priority should be deleted first). > But again, it this clear form RFC 3320? It only takes one or two sentences > to clarify. > > BR, > Zhigang > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 08:50:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21400 for ; Fri, 6 Jun 2003 08:50:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Co1q20460 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 08:50:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Co1B20457 for ; Fri, 6 Jun 2003 08:50:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21390 for ; Fri, 6 Jun 2003 08:49:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGdY-0001cg-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:48:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OGdX-0001cd-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:48:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CnUB20422; Fri, 6 Jun 2003 08:49:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CmYB20395 for ; Fri, 6 Jun 2003 08:48:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21170 for ; Fri, 6 Jun 2003 08:48:30 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGc9-0001Xz-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:46:37 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19OGby-0001XE-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:46:29 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h56Cm4b15552 for ; Fri, 6 Jun 2003 07:48:04 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 07:48:11 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 07:47:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 07:47:24 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139885D@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-TCP: Update and some topics to be discussed Thread-Index: AcMrcZ5Kqk3L8oeIS1mDKDQV81xeYwAtf1wA To: Cc: X-OriginalArrivalTime: 06 Jun 2003 12:47:26.0037 (UTC) FILETIME=[C82FE850:01C32C29] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56CmYB20396 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h56CnUB20422 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56Co1B20457 Content-Transfer-Encoding: 8bit Hi Ghyslain, Thanks for providing clarification. Few inline comments below. Regards, Yousuf -----Original Message----- From: ext Ghyslain Pelletier [mailto:Ghyslain.Pelletier@epl.ericsson.se] Sent: Thursday, June 05, 2003 9:45 AM To: Saifullah Yousuf (NRC/Dallas) Cc: rohc@ietf.org Subject: Re: [rohc] ROHC-TCP: Update and some topics to be discussed Hi Yousuf, Thanks for your comments. Some answers in-line. I will get back to some of the issues I won't address in this mail in a later mail. Regards, /Ghyslain Yousuf.Saifullah@nokia.com wrote: > > Hi Gyslain, > > The following are my comments on the context replication draft (draft-pelletier-rohc-context-replication-00.txt): > > - Section 3.2.2: What is "OPTIONAL improved forward transition"? > I was not able to find any description for this term. This is written in the same way as in RFC-3095, section 5.4.1.1. Basically, what this means is that it is not necessary - the compressor may still transit to a higher state, but it can help such a transition to happen faster. > - Section 3.2.2.1 - last two paras: NACK is not sent in response to > IR-REPLICATE. Instead, it looks like that it is a general failure > information procedure for informing decompression of a subsequent > packet not IR-REPLICATE. I think these two paras are irrelevant to > context replication. I'd suggest to either take out these paras or > explicitly mention that this is a general failure procedure. I am not sure that I understand the first statement in the comment. What do you mean by "NACK is not sent in response to IR-REPLICATE"? I'd like you to bring some precisions so I can bring you a better answer. Section 3.3.2. of the draft states that the decompressor can send a NACK in response to an IR-REPLICATE in some cases. [Yousuf] Your answer under the following comment has provided the clarification. Thanks! > - Section 3.3.2 - Third para: Could you please clarify when the > compressor will be sending IR-REPLICATE packets as subsequent packets > after receiving ACK for successful decompression of the initial > IR-REPLICATE. The decompressor after successfully validating > IR-REPLICATE will send ACK, which moves the compressor from IR to CO > state (taking ROHC-TCP state machine). I think in this state the > compressor will be sending compressed packets not IR-REPLICATE. I think that we do not prevent the IR-REPLICATE to be sent and decompressed in other states than IR state, that is we do not prevent it (and I don't think we can anyway) to be used as an ordinary packet. [snip] [I'll get back on the feedback and failure mechanism.] [I think this should be taken separately.] > > Section 3.4.1 - third para: The way I understood this para is that > the 8-bit CRC could cover entire IR header but a profile may not do > that and the reason is in section 5.2.6 of RFC 3095. I was unable to > find the explanation in the reference, could you please explain this > limitation. Recall point 10) in section 5.2.6. of RFC-3095 states: 10) If the packet type is IR, the profile indicated in the IR packet determines how it is to be processed. If the CRC fails to verify the packet, it MUST be discarded. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, no further action is taken. This is framework logic, and the IR-REPLICATE is also an IR packet. The text in the context replication draft states the consequence of that point for the IR-REPLICATE regarding the type of CRC, its presence in an IR packet (thus this applies to the IR-REPLICATE as well) and nature of what it protects (e.g. it cannot be redefined to cover say the original uncompressed header instead). Therefore only the extent of the CRC coverage can be redefined by a profile and it must meet the minimal coverage required (CID, Profile, etc. - that is at least the initial part of the packet ending with the Profile field). [Yousuf] The above text is clearer than the text in the draft. You may like to use the above clarification in the draft. > Section 3.4.2 - IR-REPLICATE format figure: I think it would be more > clear to show 7-bit CRC and Base CID in the figure. These fields are > described but are not shown in the figure. The 7-bit CRC (always present) and the Base CID (if present) are both part of the profile specific information. This means that how they are to be represented in the format depends on the packet format defined by a specific profile, and this may vary from one profile to another. Therefore it would not be appropriate in my opinion to show these fields in the figure. Consider for example a profile that would define two "sets" of packet formats, one of which includes the Base CID for when the compressor wants to create a different context and keep the base context, and one that doesn't for when we want to overwrite the base context. Another profile might be defined so that the Base CID field is always present in the format. Still, it is appropriate for the text to mandate the presence of a 7-bit CRC in the packet and mention that an identifier to the Base CID may be present because these belong to the replication mechanism - their functionality and nature is defined by context replication. > Appendix A: Is this the intention that the formats mentioned in this > Appendix will become standardized format? If that is the case, then I > would suggest to put these formats in the main body of the draft not > in appendix. The appendix is informative. This is simply a suggestion to exemplify a possible structure to the IR-REPLICATE packet. Other approaches than chains (for example) might be taken. As said previously, this part is profile specific, so I am not sure how/if we can make this part normative in this document. See also my reply to Richard's comments on this. [Yousuf] At this moment the draft is suggesting it. But, eventually the format of IR-REPLICATE packet per profile needs to be standardized. If not this document then may be the per profile document would be the place to put this format as normative text. > A.1: Why didn't we define a flag for marking Traffic Class as > replicable? Is this because adding a bit would mean adding a byte and > that would exactly be the saving in the Traffic class case? This can be added without requiring another octet. We could use codes insteads of flags. As Richard pointed out, we could also add hop limit as well. I can update that. [Yousuf] That would be good. I would also support using codes and add all the fields. > A.2: The two spare bits left in the first byte can be used for the > replication flags for Type of Service and Identification fields. This > will not cause any addition in the packet size. Could you please > define the spare bits as the flags. Yes, I can do that. As Richard pointed out, we could also add TTL as well. Thanks for your comment. I will get back on the question I haven't answered in a later mail. /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 70 609 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 08:56:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21810 for ; Fri, 6 Jun 2003 08:56:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Cta120805 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 08:55:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CtaB20802 for ; Fri, 6 Jun 2003 08:55:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21780 for ; Fri, 6 Jun 2003 08:55:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGix-0001kQ-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:53:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OGix-0001kN-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 08:53:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Ct7B20769; Fri, 6 Jun 2003 08:55:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Cs8B20674 for ; Fri, 6 Jun 2003 08:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21579 for ; Fri, 6 Jun 2003 08:54:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGhY-0001gd-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:52:12 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19OGhX-0001gZ-00 for rohc@ietf.org; Fri, 06 Jun 2003 08:52:11 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 13:54:04 +0100 Message-ID: From: "Price, Richard" To: "'Paulius.Meskauskas@nokia.com'" , Jan.Christoffersson@epl.ericsson.se, zhigang.c.liu@nokia.com, Lajos.Zaccomer@eth.ericsson.se, rohc@ietf.org Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 13:53:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > I agree with Jan that endpoint must never decrease the resources. Hi Paulius, A well-behaved implementation should definitely try to avoid decreasing the resources on-the-fly. However, if it can't avoid doing this for whatever reason, then it's much better to decrease the available resources in a way that prevents decompression failures from occurring. > I see one possible problem with Richard's implementation suggestion: > > the client of the SigComp instructs the SigComp > to decrease the sms of the compartment for instance > due to low memory condition in the mobile terminal. > But endpoint can free actually the resources after > it receives an ack from the remote endpoint. It is possible > that the endpoint can't decrease the resources in order > to avoid synchronization problems. IMO this should not > be allowed to happen in the mobile terminal. The "safe" way to decrease the resources on-the-fly is to announce the decrease using the SigComp feedback mechanism, and to defer actually reclaiming the resources until the relevant message is ACKed. In some cases even this may be impossible (e.g. if the memory simply stops working!). Of course, if this happens then we may get decompression failures, so we should try to avoid this worst- case scenario if at all possible. Regards, Richard > > -----Original Message----- > > From: ext Jan Christoffersson (EAB) > > [mailto:Jan.Christoffersson@epl.ericsson.se] > > Sent: 06 June, 2003 10:58 > > To: Jan Christoffersson (EAB); Liu Zhigang.C (NRC/Dallas); > > richard.price@roke.co.uk; Lajos Zaccomer (ETH); Meskauskas Paulius > > (NMP/Helsinki); rohc@ietf.org > > Subject: RE: [rohc] Dynamic update of resources in SigComp > > > > > > Correction: it should be the 'S' bit, not the 'I' bit in my > > reply below :-) > > > > /Jan > > > > -----Original Message----- > > From: Jan Christoffersson (EAB) > > Sent: den 6 juni 2003 08:43 > > To: 'zhigang.c.liu@nokia.com'; richard.price@roke.co.uk; > > Lajos Zaccomer > > (ETH); Paulius.Meskauskas@nokia.com; rohc@ietf.org > > Subject: RE: [rohc] Dynamic update of resources in SigComp > > > > > > Hi Folks, > > > > As far as I remember, there is only one exception to the rule > > that an endpoint must not decrease its resources and that is > > if the compressor sets the 'I' bit to 1, then it's ok for the > > other endpoint to reduce (or set to zero) the state memory > > size. Apart from this, an endpoint should never decrease its > > resources. > > As Zhigang says, reducing the available recources on the fly > > would make life much more complicated and this was the reason > > why the idea was that they should only be increased and never > > decreased! > > > > However, looking through RFC 3320 I cannot find that this is > > very clearly written. In section 3.3 it says: > > "Each parameter has a minimum value that MUST be offered by all > > receiving SigComp endpoints. Moreover, endpoints MAY offer > > additional resources if available; these resources can be advertised > > to remote endpoints using the SigComp feedback mechanism." > > > > Unfortunately, to me this is not clear enough. I agree with > > Zhigang that this should be made clearer. Perhaps this is > > something for the Implementors Guide to begin with? > > > > Regards, > > Jan > > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: den 5 juni 2003 19:04 > > To: richard.price@roke.co.uk; Lajos Zaccomer (ETH); > > Paulius.Meskauskas@nokia.com; rohc@ietf.org > > Subject: RE: [rohc] Dynamic update of resources in SigComp > > > > > > Richard, > > > > > This was true for an early version of SigComp, but we remembered > > > to fix it before publishing the final RFC ;-) > > > > I also remember we had discussion whether to allow reducing resource > > dynamically. Decreasing seemed trickier than increasing. So, at one > > time, we disallowed it. But I cannot recall details how we reversed > > it later? In particular, I couldn't find text in RFC 3320 on this, > > or perhaps I missed it? > > > > > True synchronisation is always impossible over an unreliable > > > transport, but the SigComp Feedback mechanism is designed to > > > ensure that this isn't a problem. It works much like R-mode of > > > RFC 3095, using the following general rule: > > > > > > "Don't assume that any data has arrived until you get an > > > explicit acknowledgement." > > > > > > So, for example, a compressor should not attempt to access a state > > > item unless it receives an explicit acknowledgment that the state > > > has been created by the remote endpoint. > > > > Right. But when an endpoint reduces its SMS, even previously acknowledged > > state(s) may have to be deleted. Then the order of deletion is important > > to maintain synchronization. Presumably, state_retention_priority should > > be used for this purpose (i.e. lowest priority should be deleted first). > > But again, it this clear form RFC 3320? It only takes one or two sentences > > to clarify. > > > > BR, > > Zhigang > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 09:25:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22568 for ; Fri, 6 Jun 2003 09:25:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56DOtX22944 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 09:24:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DOtB22941 for ; Fri, 6 Jun 2003 09:24:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22500 for ; Fri, 6 Jun 2003 09:24:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHBJ-0001wv-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 09:22:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OHBJ-0001wr-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 09:22:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DOQB22862; Fri, 6 Jun 2003 09:24:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DNCB22825 for ; Fri, 6 Jun 2003 09:23:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22455 for ; Fri, 6 Jun 2003 09:23:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OH9f-0001vy-00 for rohc@ietf.org; Fri, 06 Jun 2003 09:21:15 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OH9e-0001vu-00 for rohc@ietf.org; Fri, 06 Jun 2003 09:21:14 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56DNlbj030757 for ; Fri, 6 Jun 2003 15:23:47 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Jun 2003 15:22:52 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 15:22:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > I would also support Richard's thoughts that we should not > limit replication to few fields, like addresses and ports. > Also, using codes instead of flags is not adding complexity. If there had been any concrete arguments for doing so, that had made sense. However, the usefulness of it has not been presented. Actually, Carsten has several times asked us if we can really present convincing arguments for context replication in general, which is a good guestion (still to be answered). /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 10:34:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26160 for ; Fri, 6 Jun 2003 10:34:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56EXur28253 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 10:33:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EXtB28250 for ; Fri, 6 Jun 2003 10:33:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26133 for ; Fri, 6 Jun 2003 10:33:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIG5-0002ZM-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 10:31:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OIG4-0002ZJ-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 10:31:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EXRB28200; Fri, 6 Jun 2003 10:33:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EWeB28111 for ; Fri, 6 Jun 2003 10:32:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26048 for ; Fri, 6 Jun 2003 10:32:34 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIEr-0002YS-00 for rohc@ietf.org; Fri, 06 Jun 2003 10:30:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19OIEq-0002YK-00 for rohc@ietf.org; Fri, 06 Jun 2003 10:30:40 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h56EWXD24639 for ; Fri, 6 Jun 2003 17:32:33 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 17:32:31 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 17:32:31 +0300 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 07:31:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 09:31:39 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139885E@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-TCP: Update and some topics to be discussed Thread-Index: AcMsLwQlhcobXP+zRFexVGUXEihKoQAA4F2g To: , X-OriginalArrivalTime: 06 Jun 2003 14:31:39.0903 (UTC) FILETIME=[57C820F0:01C32C38] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56EWeB28112 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The main argument is that developing a protocol with unnecessary limitation is going to limit the usefulness of the protocol. If replication could use fields other than addresses and ports from the base context, then that should be allowed in the protocol. This will provide more saving in the context establishment packet size. Regarding the usefulness of context replication in general, one good argument is that the context replication reduces the size of context establishment packet. Thus, it performs compression right from the very first packet. This is more useful in short lived transactions. Without context replication the compressor will be sending the full header for context establishment. The compressor does not start compression until it is confident that the decompressor has built the context. The transfer of full header may continue for more than one packet, and by the time the compressor is confident the transaction could be over. Another advantage is that decreasing the size of context establishment packet also decreases the transmission time and the chance of transmission error on the packet between the compressor and decompressor. Both of these help in speeding up the context build up at the decompressor, which in turn helps in faster transition into more efficient compression/decompression states. Regards, Yousuf -----Original Message----- From: ext Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] Sent: Friday, June 06, 2003 8:23 AM To: rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed > I would also support Richard's thoughts that we should not > limit replication to few fields, like addresses and ports. > Also, using codes instead of flags is not adding complexity. If there had been any concrete arguments for doing so, that had made sense. However, the usefulness of it has not been presented. Actually, Carsten has several times asked us if we can really present convincing arguments for context replication in general, which is a good guestion (still to be answered). /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 11:05:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27544 for ; Fri, 6 Jun 2003 11:05:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56F4mE30985 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 11:04:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F4mB30982 for ; Fri, 6 Jun 2003 11:04:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27513 for ; Fri, 6 Jun 2003 11:04:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIjx-0002qn-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 11:02:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OIjw-0002qk-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 11:02:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F4NB30964; Fri, 6 Jun 2003 11:04:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F3fB30905 for ; Fri, 6 Jun 2003 11:03:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27469 for ; Fri, 6 Jun 2003 11:03:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIis-0002qK-00 for rohc@ietf.org; Fri, 06 Jun 2003 11:01:42 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OIir-0002qH-00 for rohc@ietf.org; Fri, 06 Jun 2003 11:01:41 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56F3YT3000475 for ; Fri, 6 Jun 2003 17:03:34 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Jun 2003 17:03:20 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 17:03:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Yousuf, > Regarding the usefulness of context replication in general, > one good argument is that the context replication reduces the > size of context establishment packet. Thus, it performs > compression right from the very first packet. > > This is more useful in short lived transactions. Without > context replication the compressor will be sending the full > header for context establishment. The compressor does not > start compression until it is confident that the decompressor > has built the context. The transfer of full header may > continue for more than one packet, and by the time the > compressor is confident the transaction could be over. > > Another advantage is that decreasing the size of context > establishment packet also decreases the transmission time and > the chance of transmission error on the packet between the > compressor and decompressor. Both of these help in speeding > up the context build up at the decompressor, which in turn > helps in faster transition into more efficient > compression/decompression states. We all know about these general arguments, but we must... 1) find "reasonable" cases when it really is possible to replicate 2) show that the relative gain is significant enough to justify new protocol solutions These are questions that should be addressed for each new field we intend to add replication support for. > The main argument is that developing a protocol with > unnecessary limitation is going to limit the usefulness of > the protocol. It is a fairly well established protocol design practice to limit protocol functionality to what is really useful. There are too many unnecessary complex protocols out there, and we have seen many cases where protocols are "re-used" for new things just because they "could easily be extended for new purposes", while it in general is not a technically good idea. > If replication could use fields other than > addresses and ports from the base context, then that should > be allowed in the protocol. This will provide more saving in > the context establishment packet size. If one can show 1) and 2) above, I might agree with you. It is our mission to develop useful standards to address known problems, but nothing more than that! /L-E P.S. Note that I personally believe there are cases when context replication might be useful. However, we are playing a dangerous game here if we start adding more functionality just because we think it is cool (and possible to do). We have to show that what we develop is really useful. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 11:08:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27687 for ; Fri, 6 Jun 2003 11:08:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56F8Oe32102 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 11:08:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F8OB32099 for ; Fri, 6 Jun 2003 11:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27643 for ; Fri, 6 Jun 2003 11:08:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OInQ-0002sE-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 11:06:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OInP-0002sB-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 11:06:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F82B32044; Fri, 6 Jun 2003 11:08:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F7sB31956 for ; Fri, 6 Jun 2003 11:07:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27632 for ; Fri, 6 Jun 2003 11:07:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OImw-0002s3-00 for rohc@ietf.org; Fri, 06 Jun 2003 11:05:54 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19OImv-0002s0-00 for rohc@ietf.org; Fri, 06 Jun 2003 11:05:53 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 16:07:47 +0100 Message-ID: From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 16:07:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Context replication in general is extremely easy to justify, due to the importance of getting a good compression ratio even on short-lived TCP flows. For example, consider one or more wireless SIP call setups running over TCP (with compression of both SIP and TCP over the wireless link). Each call setup will only consist of a handful of packets in each direction, so "conventional" ROHC context establishment will get little (if any) compression of the TCP headers before the connection closes. In SigComp we provided several mechanisms for optimising the compression of short-lived flows (static dictionary, user-specific dictionary etc.), and for TCP we must do the same. Context replication will help significantly in the wireless environment by allowing us to take advantage of redundancy between different TCP connections (as the proposed packet formats show, we can get a 60-byte TCP/IPv6 header down to just 15 bytes even for the first packet of the flow). Regards, Richard > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Friday, June 06, 2003 2:23 PM > To: rohc@ietf.org > Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed > > > > > I would also support Richard's thoughts that we should not > > limit replication to few fields, like addresses and ports. > > Also, using codes instead of flags is not adding complexity. > > If there had been any concrete arguments for doing so, that > had made sense. However, the usefulness of it has not been > presented. Actually, Carsten has several times asked us if we > can really present convincing arguments for context replication > in general, which is a good guestion (still to be answered). > > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 11:59:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29746 for ; Fri, 6 Jun 2003 11:59:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FwhG03648 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 11:58:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FwhB03645 for ; Fri, 6 Jun 2003 11:58:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29718 for ; Fri, 6 Jun 2003 11:58:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJaB-0003Qa-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 11:56:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OJaB-0003QX-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 11:56:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FwFB03615; Fri, 6 Jun 2003 11:58:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FveB03547 for ; Fri, 6 Jun 2003 11:57:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29661 for ; Fri, 6 Jun 2003 11:57:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJZA-0003PW-00 for rohc@ietf.org; Fri, 06 Jun 2003 11:55:44 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19OJZA-0003P0-00 for rohc@ietf.org; Fri, 06 Jun 2003 11:55:44 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 16:57:07 +0100 Message-ID: From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 16:57:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Yousuf, > We all know about these general arguments, but we must... > > 1) find "reasonable" cases when it really is possible to replicate > 2) show that the relative gain is significant enough to justify > new protocol solutions Hi, I'd like to expand on my previous post with some concrete numbers (which I hasten to add are only rough-and-ready approximations, but hopefully should be good enough for our needs). As a rough ballpark, in a 3G network we're aiming for a total call setup time of between 1-2s. Anything above 2s we consider unacceptable, and we believe that new protocol solutions are required. Anything below 1s is "optimal", and further gain is not especially important. Anything between 1-2s is "good enough" - obviously the closer to 1s the better, but we would need to take into account other factors such as protocol complexity before necessarily opting for the more efficient solution. A typical 3GPP call setup requires around 12 SIP messages (6 in each direction). Total time to send these messages over an 8 kbit/s bearer is around 10s - completely unacceptable! With SigComp we can reduce the time to send the SIP messages themselves down to around 1.5s, which we consider to be "good enough". However, if we have to send the underlying TCP/IPv6 headers in full then we add an additional 12 * 60 / 1000 = 0.72s delay, bringing the total call setup delay to around 2.25s (plus any processing delay). This is outside the band that we're aiming for. Thus, it would be really useful to be able to cut at least 1/3rd off the average size of a TCP/IPv6 header, even when the number of packets in the flow is very small. With conventional ROHC context establishment mechanisms this is unlikely to be possible (particularly if SIP is opening connections on a per-transaction basis, i.e. every 2-3 messages). Therefore, I believe that we're justified in considering context replication to improve the compression ratio of short-lived flows. > These are questions that should be addressed for each new field we > intend to add replication support for. Alternatively, why not just base the IR-REPLICATE packets on the ordinary CO packets themselves? This will give us much more flexibility, and at less cost than creating brand new IR-REPLICATE packets completely from scratch. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 12:33:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01670 for ; Fri, 6 Jun 2003 12:33:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56GXIf07644 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 12:33:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GXIB07641 for ; Fri, 6 Jun 2003 12:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01640 for ; Fri, 6 Jun 2003 12:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OK7d-0003wf-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 12:31:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OK7d-0003wc-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 12:31:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GWLB07500; Fri, 6 Jun 2003 12:32:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GUWB07309 for ; Fri, 6 Jun 2003 12:30:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01325 for ; Fri, 6 Jun 2003 12:30:28 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OK4y-0003qt-00 for rohc@ietf.org; Fri, 06 Jun 2003 12:28:36 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19OK4w-0003qq-00 for rohc@ietf.org; Fri, 06 Jun 2003 12:28:35 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h56GUK125014 for ; Fri, 6 Jun 2003 11:30:20 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 11:30:17 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 09:29:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Fri, 6 Jun 2003 11:29:02 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139885F@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-TCP: Update and some topics to be discussed Thread-Index: AcMsPPGTQhGtctMkQkSdg9sXfychQAABLK/w To: , X-OriginalArrivalTime: 06 Jun 2003 16:29:03.0402 (UTC) FILETIME=[BE08C8A0:01C32C48] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56GUWB07310 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Lars-Erik, > -----Original Message----- > From: ext Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Friday, June 06, 2003 10:03 AM > To: rohc@ietf.org > Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed > > > Yousuf, > > > Regarding the usefulness of context replication in general, > > one good argument is that the context replication reduces the > > size of context establishment packet. Thus, it performs > > compression right from the very first packet. > > > > This is more useful in short lived transactions. Without > > context replication the compressor will be sending the full > > header for context establishment. The compressor does not > > start compression until it is confident that the decompressor > > has built the context. The transfer of full header may > > continue for more than one packet, and by the time the > > compressor is confident the transaction could be over. > > > > Another advantage is that decreasing the size of context > > establishment packet also decreases the transmission time and > > the chance of transmission error on the packet between the > > compressor and decompressor. Both of these help in speeding > > up the context build up at the decompressor, which in turn > > helps in faster transition into more efficient > > compression/decompression states. > > We all know about these general arguments, but we must... [Yousuf] Good! At least we agree that context replication in general is useful :) > > 1) find "reasonable" cases when it really is possible to replicate > 2) show that the relative gain is significant enough to justify > new protocol solutions > > These are questions that should be addressed for each new field we > intend to add replication support for. > > > > The main argument is that developing a protocol with > > unnecessary limitation is going to limit the usefulness of > > the protocol. > > It is a fairly well established protocol design practice to limit > protocol functionality to what is really useful. There are too > many unnecessary complex protocols out there, and we have seen > many cases where protocols are "re-used" for new things just > because they "could easily be extended for new purposes", while > it in general is not a technically good idea. > [Yousuf] Using codes instead of flags (the idea from an earlier email from Richard) is not adding any complexity and is also not adding any new protocol solution. The bits which are defined as flags will be defined as codes. They will be used in the same way for addresses and ports as for any other fields. Therefore, I don't see 2) as a concern. Regarding 1), any field replication is a saving. If the same code mechanism can do that without adding any bits in the IR-REPLICATE format then I don't see a problem. IMHO there are protocols out there and their flexibility has made them more useful and popular without compromising any technicality. Regards, Yousuf _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 12:55:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02265 for ; Fri, 6 Jun 2003 12:55:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Gsov09393 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 12:54:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GsnB09390 for ; Fri, 6 Jun 2003 12:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02255 for ; Fri, 6 Jun 2003 12:54:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKSS-00047O-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 12:52:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OKSS-00047K-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 12:52:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GrqB09364; Fri, 6 Jun 2003 12:53:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GqCB09302 for ; Fri, 6 Jun 2003 12:52:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02196 for ; Fri, 6 Jun 2003 12:52:07 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKPv-00046M-00 for rohc@ietf.org; Fri, 06 Jun 2003 12:50:15 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19OKPt-00046I-00 for rohc@ietf.org; Fri, 06 Jun 2003 12:50:14 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h56Gq2128013 for ; Fri, 6 Jun 2003 11:52:02 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 11:52:02 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 09:52:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Dynamic update of resources in SigComp Date: Fri, 6 Jun 2003 11:52:00 -0500 Message-ID: Thread-Topic: [rohc] Dynamic update of resources in SigComp Thread-Index: AcMsKMmuGWXK210VQua6dq2LhOCZNwAGgmTg To: , , , , X-OriginalArrivalTime: 06 Jun 2003 16:52:02.0177 (UTC) FILETIME=[F3D92710:01C32C4B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56GqCB09303 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > > As Zhigang says, reducing the available recources on the fly > > would make life much more complicated and this was the reason > > why the idea was that they should only be increased and never > > decreased! > > Same applies for increasing the resources on-the-fly as well > (this never causes decompression failure, but it's awkward for > an endpoint to take advantage of extra resources mid-call, so > the majority of endpoints will simply ignore the additional > resources altogether). Richard, I agree with your reasoning that an endpoint may be *forced* to reduce its offered resources (who can prevent an endpoint from malfunction/crash?). However, I disagree with your above statement. I think we have been discussing synchronization issue. From that point of view, (monotonically) increasing offered resources clearly makes it much simpler than allowing decreasing resources. A SigComp sending point can just rely on the latest announcement from its peer, without worrying about loss and misordering of the announcements. This is not true for decreasing. Now, you seem to say increasing resources on-the-fly is not very useful. This is another issue. And I'm not sure that is the case. For example, a larger SMS can allow more states being created which in turn may improve compression ratio. A larger DMS can allow a larger ring buffer which may also lead to better performance. In summary, I think the clarification should focus on synchronization issue, i.e., how it works and what are the potential problems. This is the responsibility of a protocol (or rather its designers). As to how an implementation uses the synchronization mechanism, we should be open-minded and let implementers make their own minds. (In fact, if dynamically increasing resource is not useful at all, why it has not been excluded from SigComp in the first place?) BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 6 23:10:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22657 for ; Fri, 6 Jun 2003 23:10:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5739st21937 for rohc-archive@odin.ietf.org; Fri, 6 Jun 2003 23:09:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5739sB21934 for ; Fri, 6 Jun 2003 23:09:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22648 for ; Fri, 6 Jun 2003 23:09:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OU3c-0000uC-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 23:07:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OU3b-0000u9-00 for rohc-web-archive@ietf.org; Fri, 06 Jun 2003 23:07:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5739TB21923; Fri, 6 Jun 2003 23:09:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5738dB21900 for ; Fri, 6 Jun 2003 23:08:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22633 for ; Fri, 6 Jun 2003 23:08:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OU2P-0000to-00 for rohc@ietf.org; Fri, 06 Jun 2003 23:06:37 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19OU2N-0000tf-00 for rohc@ietf.org; Fri, 06 Jun 2003 23:06:36 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id E93528A75F; Sat, 7 Jun 2003 12:37:57 +0930 (CST) Date: Sat, 7 Jun 2003 12:37:57 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030607123757.A31354@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] RFC 3095 question: RX context update rules for CSRC lists Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , I'm having difficulty getting complete clarity on exactly what is and isn't updated for CSRC lists, CSRC sliding windows and CSRC translation tables in the decompressor (RX) context for profile 0x0001 in RFC 3095. There is some attempt at clarification in the ROHC Implementer's guide, version 2, 4.15, page 9, but this confuses me even more. Could anyone please tell me if I have inferred the right procedures for the decompressor here? A systematic clarification such as this could be a useful addition to the Implementer's Guide. It's important for interoperability that the TX context should know whether the RX context will update its lists and windows. Therefore there should be clarity in this. Obviously implementers should not have to use guesswork for questions which affect interoperability. In my opinion, the complete set of context-updating rules should be presented systematically in tables in the Implementer's Guide because natural langauge is too confusing. Event: Arrival of UO-1-ID packet with extension 3 containing CSRC list using generic encoding 0 or delta encodings 1, 2 or 3. If the CRC-3 fails, the complete packet is discarded and ignored. Otherwise: - The received CSRC list is used to construct a header for the payload. - The current CSRC list is _not_ updated by the received list. - The received CSRC list is _not_ inserted into the sliding window. - Any (index, item) pairs in the CSRC list _do_ update the CSRC translation table. (Implied by Implementer's guide, 4.15.) - In R-mode, an ACK _is_ required? RFC 3095, 5.8.2(e), page 109, is unclear about this. Most likely an ACK must be sent because there is a partial context update, but there is no benefit in this because the sliding window is not updated. In U/O modes, probably the CSRC list should not be ACKed if gen_id field is not set? Event: Arrival of R-1* packet with extension 3 containing CSRC list using generic encoding 0 or delta encodings 1, 2 or 3. - The received CSRC list is used to construct a header for the payload. - The current CSRC list is _not_ updated by the received list. - The received CSRC list is _not_ inserted into the sliding window. - Any (index, item) pairs in the CSRC list do _not_ update the CSRC translation table? - An ACK is _not_ required in any mode. In other words, absolutely nothing in the RX context is updated. But the Implementer's guide, 4.15, could be taken to imply that the CSRC translation table _is_ updated, even though there is no CRC. If the translation table is udpated, then must an ACK be sent in R-mode? Event: Arrival of UOR-2* packet with extension 3 containing CSRC list using generic encoding 0 or delta encodings 1, 2 or 3. If the CRC-7 fails, the complete packet is discarded and ignored. Otherwise: - The received CSRC list is used to construct a header for the payload. - The current CSRC list _is_ updated by the received list. - The received CSRC list _is_ inserted into the sliding window if mode=R, or if mode=U/O and the gen_id header field is set. - Any (index, item) pairs in the CSRC list _do_ update the CSRC translation table. - In R mode, an ACK must be sent. In U/O modes, an ACK may be sent. In other words, everything possible in the context is updated, except that if the gen_id field is not set and the mode is U/O, then the sliding window is not updated. Event: Arrival of IR (containing dynamic fields) or IR-DYN packet containing CSRC list using generic encoding 0. If the CRC-8 fails, the complete packet is discarded and ignored. Otherwise: - The received CSRC list is used to construct a header for the payload. - The current CSRC list _is_ updated by the received list. - The received CSRC list _is_ inserted into the sliding window if mode=R, or if mode=U/O and the gen_id header field is set. - Any (index, item) pairs in the CSRC list _do_ update the CSRC translation table. - In R mode, an ACK must be sent. In U/O modes, an ACK may be sent. In other words, everything possible in the context is updated, except that if the gen_id field is not set and the mode is U/O, then the sliding window is not updated. It seems that for IR and IR-DYN packets, only the generic scheme 0 for list encoding is permitted. (RFC 395, 5.8.2.1(a), page 107.) Otherwise, everything is the same as for the UOR-2* packets. In the above, the "current CSRC list" is used for contructing headers when the received packets does not contain a CSRC list of any kind. Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Jun 9 06:48:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27432 for ; Mon, 9 Jun 2003 06:48:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59Am5322321 for rohc-archive@odin.ietf.org; Mon, 9 Jun 2003 06:48:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Am5B22318 for ; Mon, 9 Jun 2003 06:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27413 for ; Mon, 9 Jun 2003 06:47:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PKA3-0001dj-00 for rohc-web-archive@ietf.org; Mon, 09 Jun 2003 06:45:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PKA2-0001df-00 for rohc-web-archive@ietf.org; Mon, 09 Jun 2003 06:45:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59AlWB22296; Mon, 9 Jun 2003 06:47:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59AkIB22225 for ; Mon, 9 Jun 2003 06:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27401 for ; Mon, 9 Jun 2003 06:46:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PK8K-0001dV-00 for rohc@ietf.org; Mon, 09 Jun 2003 06:44:12 -0400 Received: from mail.chungbuk.ac.kr ([203.255.66.12]) by ietf-mx with esmtp (Exim 4.12) id 19PK8J-0001d5-00 for rohc@ietf.org; Mon, 09 Jun 2003 06:44:11 -0400 Received: from mcrbcshin ([210.125.151.115]) by mail.chungbuk.ac.kr (8.12.8/8.12.8) with SMTP id h59Ab6sc028838; Mon, 9 Jun 2003 19:37:07 +0900 (JST) Message-ID: <00ba01c32e74$54535fa0$73977dd2@mcrbcshin> From: =?utf-8?B?7Iug67OR7LKg?= To: "ROHC mailing list" Cc: =?utf-8?B?7Iug67OR7LKg?= References: <20030607123757.A31354@dog.topology.org> Subject: [rohc] Is there any open source of ROHC ? Date: Mon, 9 Jun 2003 19:46:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h59AkIB22226 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Is there any open source or public domain software of ROHC implementations ? Shin, Byung-Cheol Chungbuk National university T: +82-43-261-2389 HP: +82-17-404-0239 bcshin@cbu.ac.kr _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 13 05:24:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26267 for ; Fri, 13 Jun 2003 05:24:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D9Nbo23402 for rohc-archive@odin.ietf.org; Fri, 13 Jun 2003 05:23:37 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D9Nbm23399 for ; Fri, 13 Jun 2003 05:23:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26244 for ; Fri, 13 Jun 2003 05:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QkkQ-00036W-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 05:21:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QkkQ-00036S-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 05:21:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8s1a20854; Fri, 13 Jun 2003 04:54:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8rem20829 for ; Fri, 13 Jun 2003 04:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25497 for ; Fri, 13 Jun 2003 04:53:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QkHS-0002sp-00 for rohc@ietf.org; Fri, 13 Jun 2003 04:51:30 -0400 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 19QkHS-0002sg-00 for rohc@ietf.org; Fri, 13 Jun 2003 04:51:30 -0400 Received: from windows_bb (internal.effnet.com [192.168.100.154] (may be forged)) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id h5D7r6bb028948 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 13 Jun 2003 09:53:06 +0200 Content-Type: text/plain; charset=iso-8859-1; format=flowed To: rohc@ietf.org From: Tommy Lundemo Organization: Effnet AB MIME-Version: 1.0 Date: Fri, 13 Jun 2003 10:57:33 +0200 Message-ID: User-Agent: Opera7.11/Win32 M2 build 2887 Subject: [rohc] (no subject) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all! Would it be useful to introduce means for the compressor to reject a mode change? It seems like all the mode changes that requires the compressor to send an IR/IR-DYN/UOR-2 packet could have used use the reserved bit pattern for mode, to reject a mode change. This could give more flexibility to ROHC implementations where either O or R mode does not make sense to use. Is there any specific reason why the compressor is not allowed to have an opinion in the mode changing procedure? Best Regards, Tommy Lundemo ------------------------------------------- Effnet AB http://www.effnet.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 13 06:09:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27156 for ; Fri, 13 Jun 2003 06:09:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DA9TT27432 for rohc-archive@odin.ietf.org; Fri, 13 Jun 2003 06:09:29 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DA9Tm27429 for ; Fri, 13 Jun 2003 06:09:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27150 for ; Fri, 13 Jun 2003 06:09:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QlSo-0003LZ-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 06:07:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QlSn-0003LW-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 06:07:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8m2a20514; Fri, 13 Jun 2003 04:48:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8lJm20477 for ; Fri, 13 Jun 2003 04:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25355 for ; Fri, 13 Jun 2003 04:47:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QkBJ-0002qB-00 for rohc@ietf.org; Fri, 13 Jun 2003 04:45:09 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19QkBJ-0002q8-00 for rohc@ietf.org; Fri, 13 Jun 2003 04:45:09 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5D8m3cv028642 for ; Fri, 13 Jun 2003 10:48:04 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 13 Jun 2003 10:47:07 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Fri, 13 Jun 2003 10:46:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Context replication as a separate document? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , ROHCers, We have had some discussions around the context replication draft submitted by Ghyslain a few weeks ago. As I think it would be useful to get that draft updated before Vienna to reflect the outcome of these discussions, I would like to know your opinions on keeping this material in a separate document instead of in ROHC TCP itself. If so, we should make it a new WG document. Please let us know your opinions not later than Monday, 16th. Thanks! /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 mailnull@www1.ietf.org Fri Jun 13 12:45:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11563 for ; Fri, 13 Jun 2003 12:45:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGj9U28878 for rohc-archive@odin.ietf.org; Fri, 13 Jun 2003 12:45:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGj9m28875 for ; Fri, 13 Jun 2003 12:45:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11539 for ; Fri, 13 Jun 2003 12:45:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrdj-0006ad-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 12:42:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrdi-0006aa-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 12:42:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8i1a20348; Fri, 13 Jun 2003 04:44:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8h5m20283 for ; Fri, 13 Jun 2003 04:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25308 for ; Fri, 13 Jun 2003 04:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qk7D-0002oj-00 for rohc@ietf.org; Fri, 13 Jun 2003 04:40:55 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Qk7C-0002og-00 for rohc@ietf.org; Fri, 13 Jun 2003 04:40:54 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5D8h2w2009498 for ; Fri, 13 Jun 2003 10:43:02 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 13 Jun 2003 10:42:52 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: Should we adopt this as a WG document?: [rohc] I-D ACTION:dra ft-p rice-rohc-sigcomp-user-guide-02.txt Date: Fri, 13 Jun 2003 10:42:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , A gently reminder: We still have not received any responses to this request. If we do not get any other opinions, me and Carsten will have to figure out ourselves if we find this document important to bring further as a WG document. Thanks in advance for your input! /L-E > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > Sent: den 16 maj 2003 15:20 > To: rohc@ietf.org > Subject: Should we adopt this as a WG document?: [rohc] I-D > ACTION:draft-p rice-rohc-sigcomp-user-guide-02.txt > > > Dear all, > > The SigComp User Guide has been around for some time, but is only > an individual draft. However, it is our feeling that people really > consider this a document that should/will be published as an > informational RFC, and therefore it would be appropriate to adopt > it as a WG draft. > > Please let us know your opinions about making this a WG document. > We would also like to know if you think the current document could > be adopted as is (as the starting point for evolving it as a WG doc), > or if you think we should make changes already before -00. > > Thanks, > /Lars-Erik > > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: den 16 maj 2003 13:22 > > Cc: rohc@ietf.org > > Subject: [rohc] I-D > ACTION:draft-price-rohc-sigcomp-user-guide-02.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : SigComp User Guide > > Author(s) : R. Price, A. Surtees, M. West > > Filename : draft-price-rohc-sigcomp-user-guide-02.txt > > Pages : 38 > > Date : 2003-5-15 > > > > This document provides an informational guide for users of the > > SigComp protocol. The aim of the document is to assist users when > > making SigComp implementation decisions; for example the choice of > > compression algorithm and the level of robustness against lost or > > misordered packets. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-price-rohc-sigcomp-u > ser-guide-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-price-rohc-sigcomp-user-guide-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-price-rohc-sigcomp-user-guide-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 13 12:58:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12287 for ; Fri, 13 Jun 2003 12:58:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGvoq01011 for rohc-archive@odin.ietf.org; Fri, 13 Jun 2003 12:57:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGvom01006 for ; Fri, 13 Jun 2003 12:57:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12190 for ; Fri, 13 Jun 2003 12:57:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrpz-0006jy-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 12:55:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrpy-0006jv-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 12:55:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEp2a17460; Fri, 13 Jun 2003 10:51:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEoim17421 for ; Fri, 13 Jun 2003 10:50:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08621 for ; Fri, 13 Jun 2003 10:50:41 -0400 (EDT) From: mapawar@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qpqz-0005ws-00 for rohc@ietf.org; Fri, 13 Jun 2003 10:48:33 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19Qpqx-0005wc-00 for rohc@ietf.org; Fri, 13 Jun 2003 10:48:31 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5DElaC07663 for ; Fri, 13 Jun 2003 20:17:37 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5DEla907658 for ; Fri, 13 Jun 2003 20:17:36 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h5DEp5w08437 for ; Fri, 13 Jun 2003 20:21:05 +0530 (IST) To: rohc@ietf.org Date: Fri, 13 Jun 2003 20:14:39 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 13/06/2003 08:15:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] Clarification on LSB encoding Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Dear ROHC Experts, Referring to section - 5.7 Packet Formats Can somebody explain me the concept behind lines below : ################################################################## SN: The compressed RTP Sequence Number. Compressed with W-LSB. The interpretation intervals, see section 4.5.1, are defined as follows: p = 1 if bits(SN) <= 4 p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 ################################################################## How p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 is devised ? regards, Madhusudan "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Jun 13 22:18:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02353 for ; Fri, 13 Jun 2003 22:18:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E2Hpd12472 for rohc-archive@odin.ietf.org; Fri, 13 Jun 2003 22:17:51 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2Hpm12469 for ; Fri, 13 Jun 2003 22:17:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02347 for ; Fri, 13 Jun 2003 22:17:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R0Zu-0003JK-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 22:15:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R0Zt-0003JH-00 for rohc-web-archive@ietf.org; Fri, 13 Jun 2003 22:15:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNE1a32493; Fri, 13 Jun 2003 19:14:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DND9m32377 for ; Fri, 13 Jun 2003 19:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27883 for ; Fri, 13 Jun 2003 19:13:06 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QxhC-0002Aq-00 for rohc@ietf.org; Fri, 13 Jun 2003 19:10:58 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19QxhC-0002An-00 for rohc@ietf.org; Fri, 13 Jun 2003 19:10:58 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5DND6128628 for ; Fri, 13 Jun 2003 18:13:06 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Jun 2003 18:13:05 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 16:12:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Clarification on LSB encoding Date: Fri, 13 Jun 2003 18:12:39 -0500 Message-ID: Thread-Topic: [rohc] Clarification on LSB encoding Thread-Index: AcMx3Hqo3Y9HI4EvQGuXwiM3bh2NKwAI1W9g To: , X-OriginalArrivalTime: 13 Jun 2003 23:12:39.0574 (UTC) FILETIME=[48E3A360:01C33201] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DND9m32378 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > ################################################################## > SN: The compressed RTP Sequence Number. > > Compressed with W-LSB. The interpretation intervals, > see section > 4.5.1, are defined as follows: > > p = 1 if bits(SN) <= 4 > p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 > ################################################################## > > How p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 is devised ? Hi Madhusudan, That means p=0 if bits(SN)=5, p=1 if bits(SN)=6, and so on. I.e., value of p depends on the number of SN bits carried in a compressed header. The rational is that with more SN bits (and thus larger compressed header), we want to be able to encode even misordered (before compressor) RTP packets. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sat Jun 14 03:46:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21174 for ; Sat, 14 Jun 2003 03:46:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E7k6i13388 for rohc-archive@odin.ietf.org; Sat, 14 Jun 2003 03:46:06 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E7k6m13385 for ; Sat, 14 Jun 2003 03:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21165 for ; Sat, 14 Jun 2003 03:46:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R5ha-0005Gp-00 for rohc-web-archive@ietf.org; Sat, 14 Jun 2003 03:43:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R5ha-0005Gm-00 for rohc-web-archive@ietf.org; Sat, 14 Jun 2003 03:43:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E6h1a09441; Sat, 14 Jun 2003 02:43:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E6g3m09356 for ; Sat, 14 Jun 2003 02:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20146 for ; Sat, 14 Jun 2003 02:42:00 -0400 (EDT) From: vkatyal@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R4ha-000524-00 for rohc@ietf.org; Sat, 14 Jun 2003 02:39:50 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19R4hY-00051u-00 for rohc@ietf.org; Sat, 14 Jun 2003 02:39:49 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5E6cGV15433 for ; Sat, 14 Jun 2003 12:08:16 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5E6cF915429; Sat, 14 Jun 2003 12:08:15 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h5E6fiP00320; Sat, 14 Jun 2003 12:11:44 +0530 (IST) Subject: RE: [rohc] Clarification on LSB encoding To: zhigang.c.liu@nokia.com Cc: mapawar@hss.hns.com, Date: Sat, 14 Jun 2003 12:06:38 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 14/06/2003 12:05:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Dear zhigang, Thanks for the response. Please provide the detailed analysis of the query. Refer to the table below SN p interval Comment 4 1 vref-1,vref + (2^k -1) -1 (left shift) 5 0 vref,vref+(2^k-1) (no shift) 6 1 vref-1,vref + (2^k -1) -1 (left shift) 7 3 vref-3,vref + (2^k -1) -3 (left shift) When we are using 4 bit compressed header (CH for SN, the value of p is 1 which implies that there is a left shift in the interpretation interval , where as in case of 5 bit CH p comes out to be 0, which means there is no shift in the interval. Considering SN=6 , p will be 1, again there is a left shift in interval. Now this to and fro movement is insuring correct encoding of misordered packets, How ? What is the reason behind choosing 4 and 5 in section given for calculation of p. Please elaborate on this concept. regards, Vishal zhigang.c.liu@nokia.com@ietf.org on 06/14/2003 12:12:39 AM Sent by: rohc-admin@ietf.org To: Madhusudan Pawar/HSS@HSS, cc: Subject: RE: [rohc] Clarification on LSB encoding > ################################################################## > SN: The compressed RTP Sequence Number. > > Compressed with W-LSB. The interpretation intervals, > see section > 4.5.1, are defined as follows: > > p = 1 if bits(SN) <= 4 > p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 > ################################################################## > > How p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 is devised ? Hi Madhusudan, That means p=0 if bits(SN)=5, p=1 if bits(SN)=6, and so on. I.e., value of p depends on the number of SN bits carried in a compressed header. The rational is that with more SN bits (and thus larger compressed header), we want to be able to encode even misordered (before compressor) RTP packets. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sun Jun 15 08:20:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29256 for ; Sun, 15 Jun 2003 08:20:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FCJaH28340 for rohc-archive@odin.ietf.org; Sun, 15 Jun 2003 08:19:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FCJam28337 for ; Sun, 15 Jun 2003 08:19:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29250 for ; Sun, 15 Jun 2003 08:19:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RWRm-0003EU-00 for rohc-web-archive@ietf.org; Sun, 15 Jun 2003 08:17:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RWRl-0003EQ-00 for rohc-web-archive@ietf.org; Sun, 15 Jun 2003 08:17:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FAL1a21970; Sun, 15 Jun 2003 06:21:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FAKdm21957 for ; Sun, 15 Jun 2003 06:20:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27769 for ; Sun, 15 Jun 2003 06:20:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RUae-0002ut-00 for rohc@ietf.org; Sun, 15 Jun 2003 06:18:24 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19RUad-0002up-00 for rohc@ietf.org; Sun, 15 Jun 2003 06:18:24 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 1FFE68A6E8; Sun, 15 Jun 2003 19:50:01 +0930 (CST) Date: Sun, 15 Jun 2003 19:50:00 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030615195000.A19464@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] question: default slope for TS for Tsc = 0 or 1 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On page 75 of RFC 3095, section 5.7, there's this: ====================================================== TS: The compressed RTP Timestamp value. If value(TIME_STRIDE) > 0, timer-based compression of the RTP Timestamp is used (see section 4.5.4). If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before compression (see section 4.5.3), and default-slope(TS) = 1. If value(Tsc) = 0, the Timestamp value is compressed as-is, and default-slope(TS) = value(TS_STRIDE). ====================================================== This doesn't seem right to me. Surely if Tsc = 1, then default-slope(TS) = value(TS_STRIDE), and if Tsc = 0, then default-slope(TS) = 1. Is this an error? Or have I misunderstood something? There's nothing on this in the Implementer's guide. Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sun Jun 15 09:43:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01550 for ; Sun, 15 Jun 2003 09:43:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FDgin00664 for rohc-archive@odin.ietf.org; Sun, 15 Jun 2003 09:42:44 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FDghm00661 for ; Sun, 15 Jun 2003 09:42:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01534 for ; Sun, 15 Jun 2003 09:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RXkD-0003gt-00 for rohc-web-archive@ietf.org; Sun, 15 Jun 2003 09:40:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RXkC-0003gq-00 for rohc-web-archive@ietf.org; Sun, 15 Jun 2003 09:40:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBF1a25098; Sun, 15 Jun 2003 07:15:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBEvm25082 for ; Sun, 15 Jun 2003 07:14:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28467 for ; Sun, 15 Jun 2003 07:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RVRE-00034x-00 for rohc@ietf.org; Sun, 15 Jun 2003 07:12:44 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19RVRD-00034t-00 for rohc@ietf.org; Sun, 15 Jun 2003 07:12:43 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 3403A8A774; Sun, 15 Jun 2003 20:44:23 +0930 (CST) Date: Sun, 15 Jun 2003 20:44:22 +0930 From: Alan Kennington To: ROHC mailing list Cc: Alan Kennington Message-ID: <20030615204422.A19666@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] RFC 3095 question - what is L ? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , There's a mysterious parameter L in RFC 3095. It seems to appear first in section 5.8.1, page 105. It is also in: 5.8.1.2, page 106 (twice); 5.8.2.1, page 107 (twice), page 108. As far as I can, this is never defined. Is it a fixed universal constant? Or is it perhaps a dynamic value which can respond to a-priori or measured (by the decompressor) packet loss rate? I assume that the decompressor has no way of determining this number from the compressor, and no way of forcing the compressor to adopt a particular value of L. Therefore I imagine that this is a number which must be completely free for the implemnter to choose. This is something which is not mentioned in the ROHC implementer's guide, although I think it deserves at least some comment. Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sun Jun 15 14:24:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06759 for ; Sun, 15 Jun 2003 14:24:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FINvJ15466 for rohc-archive@odin.ietf.org; Sun, 15 Jun 2003 14:23:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FINvm15461 for ; Sun, 15 Jun 2003 14:23:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06730 for ; Sun, 15 Jun 2003 14:23:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rc8L-0004Zx-00 for rohc-web-archive@ietf.org; Sun, 15 Jun 2003 14:21:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Rc8L-0004Zu-00 for rohc-web-archive@ietf.org; Sun, 15 Jun 2003 14:21:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FDw2a00996; Sun, 15 Jun 2003 09:58:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FDvRm00975 for ; Sun, 15 Jun 2003 09:57:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01679 for ; Sun, 15 Jun 2003 09:57:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RXyS-0003iu-00 for rohc@ietf.org; Sun, 15 Jun 2003 09:55:12 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19RXyQ-0003if-00 for rohc@ietf.org; Sun, 15 Jun 2003 09:55:11 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id DE9116D33B; Sun, 15 Jun 2003 23:26:50 +0930 (CST) Date: Sun, 15 Jun 2003 23:26:50 +0930 From: Alan Kennington To: ROHC mailing list Cc: Alan Kennington Subject: Re: [rohc] Clarification on LSB encoding Message-ID: <20030615232650.A20267@dog.topology.org> Reply-To: Alan Kennington References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from vkatyal@hss.hns.com on Sat, Jun 14, 2003 at 12:06:38PM +0530 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Sat, Jun 14, 2003 at 12:06:38PM +0530, vkatyal@hss.hns.com wrote: > [...] > Refer to the table below > SN p interval Comment > 4 1 vref-1,vref + (2^k -1) -1 (left shift) > 5 0 vref,vref+(2^k-1) (no shift) > 6 1 vref-1,vref + (2^k -1) -1 (left shift) > 7 3 vref-3,vref + (2^k -1) -3 (left shift) > > When we are using 4 bit compressed header (CH for SN, the value of p is 1 > which implies that there is a left shift in the interpretation interval , > where as in case of 5 bit CH p comes out to be 0, which means there is no > shift in the interval. Considering SN=6 , p will be 1, again there is a > left shift in interval. Now this to and fro movement is insuring correct > encoding of misordered packets, How ? When I first saw the rule for the interpretation interval offset function p(k), I thought it was a little quirky, probably resulting from a thinking error, but that it would not cause problems. Now I'm not so sure. The number k equals bits(SN). Therefore the interpretation intervals for d = v - v_ref are as follows: k=bits(SN) p(k) interval for d 1 1 [-1, 0] 2 1 [-1, 2] 3 1 [-1, 6] 4 1 [-1, 14] <== possible, e.g. UO-0 5 0 [ 0, 31] 6 1 [-1, 62] <== possible, e.g. R-0 7 3 [-3, 124] <== possible, e.g. R-0-CRC 8 7 [-7, 248] 9 15 [-15, 496] <== possible, e.g. R-1 extn 0. 10 31 [-31, 992] etc. If you ignore the extension type 3, the only possible SN coding widths are indicated above as "possible". This is for profiles 1, 2 and 3 anyway. Therefore it seems that it doesn't matter what you do for k = 5. However, if there was a k=5 packet format for SN fields, there is one kind of problem that could occur. This is as follows. Suppose that you have a general algorithm which determines the smallest number k_min for encoding the difference d = v - v_ref. If d = -1, your algorithm will say that k_min = 1. However, it is _not_ true that d = -1 can be encoded with k = 5. This is because the set of intervals is _not_ a non-decreasing function of k. The interval for k does not always completely include all of the intervals for smaller k. This makes it difficult to design simple algorithms for the compressor to choose the packet format. I think it is clear that the interpretation intervals should always be non-decreasing (in the set-theoretic sense) functions of k. Otherwise, almost certainly someone will write incorrect implementations because it is very difficult to code for the above irregular situation. In the case of RFC 3095, the above problem with the function p(k) is academic. However, for all future functions p(k), I believe that the interpretation interval should always include all intervals less than k. ------------------------------ Now the answer to your question, Vishal, is that the "to and fro" movement of p(k) does not ensure correct encoding of misordered packets. It is the fact that p > 0 which makes possible the correct encoding for packets where SN sometimes goes backwards, because then d < 0. So, for example, when k = 7, you can have a decrease of SN by 1, 2 or 3, but not 4. This is because p(7) = 3. Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Jun 16 09:01:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12517 for ; Mon, 16 Jun 2003 09:01:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GD0fZ00358 for rohc-archive@odin.ietf.org; Mon, 16 Jun 2003 09:00:41 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GD0em00355 for ; Mon, 16 Jun 2003 09:00:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12491 for ; Mon, 16 Jun 2003 09:00:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RtZ2-0002Q9-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 08:58:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RtZ1-0002Q5-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 08:58:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GA92a21785; Mon, 16 Jun 2003 06:09:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GA8wm21763 for ; Mon, 16 Jun 2003 06:08:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07089 for ; Mon, 16 Jun 2003 06:08:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rqsr-00017u-00 for rohc@ietf.org; Mon, 16 Jun 2003 06:06:41 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19Rqsr-00017r-00 for rohc@ietf.org; Mon, 16 Jun 2003 06:06:41 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 11:08:54 +0100 Message-ID: From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Subject: RE: [rohc] Context replication as a separate document? Date: Mon, 16 Jun 2003 11:08:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, In general, I think that a good overall structure for ROHC-TCP would be the following: * 1 draft containing the TCP-specific portion of the profile. * 1 or more drafts containing protocol-independent mechanisms, which we might want to reuse for different ROHC profiles. The packet formats for context replication are always specific to a particular profile, so I don't see any value in publishing them separately from the remainder of the packet formats. In fact, it will be a lot simpler to support context replication by modifying the existing CO packets rather than to define a whole new set of packet formats from scratch. Regarding the state machine portion of the draft, the compressor and decompressor logic is geared towards the B-mode state machine that we use for ROHC-TCP. If we want to offer context replication for another ROHC profile that uses B-mode then we can reuse this logic without modifications. However, if we need context replication for profiles with other modes then we'll need to rewrite the logic to take the different state transitions and feedback behaviour into account. Do we have any plans to use the B-mode state machine for profiles other than ROHC-TCP? If so, then it's worth keeping the context replication material in a separate draft. If not, then it would be better to keep it together with the other TCP-specific material. Regards, Richard > -----Original Message----- > From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Friday, June 13, 2003 9:47 AM > To: Rohc (E-mail) > Subject: [rohc] Context replication as a separate document? > > > ROHCers, > > We have had some discussions around the context replication > draft submitted by Ghyslain a few weeks ago. As I think it > would be useful to get that draft updated before Vienna to > reflect the outcome of these discussions, I would like to > know your opinions on keeping this material in a separate > document instead of in ROHC TCP itself. If so, we should > make it a new WG document. > > Please let us know your opinions not later than Monday, 16th. > > Thanks! > /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 mailnull@www1.ietf.org Mon Jun 16 11:23:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17761 for ; Mon, 16 Jun 2003 11:23:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GFMqV11116 for rohc-archive@odin.ietf.org; Mon, 16 Jun 2003 11:22:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFMqm11113 for ; Mon, 16 Jun 2003 11:22:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17710 for ; Mon, 16 Jun 2003 11:22:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rvme-0003KS-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 11:20:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Rvme-0003KP-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 11:20:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBv1a28208; Mon, 16 Jun 2003 07:57:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBu4m28174 for ; Mon, 16 Jun 2003 07:56:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09124; Mon, 16 Jun 2003 07:56:03 -0400 (EDT) Message-Id: <200306161156.HAA09124@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Jun 2003 07:56:03 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-tcp-requirements-06.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Requirements for ROHC IP/TCP Header Compression Author(s) : L. Jonsson Filename : draft-ietf-rohc-tcp-requirements-06.txt Pages : 9 Date : 2003-6-13 This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the ROHC WG. The document discusses the scope of TCP compression, performance considerations, assumptions on the surrounding environment, as well as IPR concerns. The structure of this document is inherited from the document defining RTP/UDP/IP requirements for ROHC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-requirements-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-tcp-requirements-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-tcp-requirements-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-16080852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-tcp-requirements-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-tcp-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-16080852.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Jun 16 15:38:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27819 for ; Mon, 16 Jun 2003 15:38:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GJcRq30083 for rohc-archive@odin.ietf.org; Mon, 16 Jun 2003 15:38:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GJcRm30079 for ; Mon, 16 Jun 2003 15:38:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27808 for ; Mon, 16 Jun 2003 15:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rzlz-0005cb-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 15:36:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Rzly-0005cY-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 15:36:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBQ1a26132; Mon, 16 Jun 2003 07:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBPom26122 for ; Mon, 16 Jun 2003 07:25:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08299 for ; Mon, 16 Jun 2003 07:25:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rs5G-0001OW-00 for rohc@ietf.org; Mon, 16 Jun 2003 07:23:34 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19Rs5E-0001OG-00 for rohc@ietf.org; Mon, 16 Jun 2003 07:23:33 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 5D6108A774; Mon, 16 Jun 2003 20:55:08 +0930 (CST) Date: Mon, 16 Jun 2003 20:55:08 +0930 From: Alan Kennington To: ROHC mailing list Cc: Alan Kennington Subject: Re: [rohc] question: default slope for TS for Tsc = 0 or 1 Message-ID: <20030616205508.A26300@dog.topology.org> Reply-To: Alan Kennington References: <20030615195000.A19464@dog.topology.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20030615195000.A19464@dog.topology.org>; from ak.rohc@topology.org on Sun, Jun 15, 2003 at 07:50:00PM +0930 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Sun, Jun 15, 2003 at 07:50:00PM +0930, Alan Kennington wrote: > On page 75 of RFC 3095, section 5.7, there's this: > > ====================================================== > TS: The compressed RTP Timestamp value. > > If value(TIME_STRIDE) > 0, timer-based compression of the RTP > Timestamp is used (see section 4.5.4). > > If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before > compression (see section 4.5.3), and default-slope(TS) = 1. > > If value(Tsc) = 0, the Timestamp value is compressed as-is, and > default-slope(TS) = value(TS_STRIDE). > ====================================================== > > This doesn't seem right to me. > Surely if Tsc = 1, then default-slope(TS) = value(TS_STRIDE), and > if Tsc = 0, then default-slope(TS) = 1. To (partly_ answer my own query, I think I understand now what the _intention_ of the above excerpt from RFC 3095 is. I think what is meant is: ======================================================== If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before compression (see section 4.5.3), and default-slope(TS) = value(TS_STRIDE). ======================================================== The rest seems to be consistent with the rest of the RFC. I interpret the above (corrected) 2 lines to mean that if two packets are to be encoded by the compressor with Tsc = 1, where SN_1 = SN of reference packet TS_1 = TS of reference packet SN_2 = SN of current packet TS_2 = TS of current packet then the predicted value for TS_2 is TS_2(predicted) = (TS_1 + (SN_2 - SN_1) * TS_STRIDE) modulo 2^32. This is (probably) the meaning of "default slope", although I don't think this is ever fully clarified in RFC 3095. Therefore the difference D = (TS_2 - TS_2(predicted)) modulo 2^32 remains to be compressed and transmitted if it is non-zero. Then the transmitted field is: floor(TS_2/TS_STRIDE) modulo 2^k I assume that it is TS_2 which is sent in this way and not D. In other words, I assume that the TS _offset_ from SN is not encoded, but rather the TS value itself. It seems to follow, therefore, that the "default slope" only determines whether the TS must be encoded in the packet or can remain implicit. But when it _is_ encoded, the default slope has no effect. --------------------------- It follows from the above that _most_ of the time, the compressed TS field will have a "slope" of 1, but this is not true when a wrap-around of TS occurs, because then the scaled TS makes a jump of -floor((2^32 - 1)/TS_STRIDE) and the compressed scaled TS makes a jump of (-floor((2^32 - 1)/TS_STRIDE)) modulo 2^k. (Note that RFC 3095, 4.5.3, page 30, does not say "floor" here although it should say this.) I think that this is the most reasonable interpretation of page 75 of RFC 3095 for the TS encoding for Tsc = 1. Can anyone tell me if this interpretation is correct? In the case of Tsc = 0, the encoding must use TS stride = 1, although the "default slope" for prediction of TS_2 is still value(TS_STRIDE). Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington website: http://www.topology.org/ city: Adelaide, South Australia coords: 138.59 E, 34.88 S timezone: UTC+0930 http://www.topology.org/site/timezone.html pgp-key: http://www.topology.org/ak/key_ak2.asc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Jun 16 17:18:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03195 for ; Mon, 16 Jun 2003 17:18:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GLHoU05475 for rohc-archive@odin.ietf.org; Mon, 16 Jun 2003 17:17:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLHnm05472 for ; Mon, 16 Jun 2003 17:17:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03178 for ; Mon, 16 Jun 2003 17:17:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S1K8-00070m-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 17:15:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S1K8-00070j-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 17:15:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFX2a11758; Mon, 16 Jun 2003 11:33:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFWJm11715 for ; Mon, 16 Jun 2003 11:32:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17953 for ; Mon, 16 Jun 2003 11:32:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rvvn-0003NB-00 for rohc@ietf.org; Mon, 16 Jun 2003 11:30:03 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Rvvm-0003N8-00 for rohc@ietf.org; Mon, 16 Jun 2003 11:30:02 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GFWGG5010978; Mon, 16 Jun 2003 17:32:16 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 16 Jun 2003 17:32:10 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Price, Richard'" , "Rohc (E-mail)" Subject: RE: [rohc] Context replication as a separate document? Date: Mon, 16 Jun 2003 17:31:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > In general, I think that a good overall structure for ROHC-TCP > would be the following: > > * 1 draft containing the TCP-specific portion of the profile. > > * 1 or more drafts containing protocol-independent mechanisms, > which we might want to reuse for different ROHC profiles. Yes, and I guess context replication is a mechanism that might be reused in the future. That is why I personally believe it makes sense to keep it separate. Especially the background and analysis is useful not to repeat in new documents. > The packet formats for context replication are always specific > to a particular profile, so I don't see any value in publishing > them separately from the remainder of the packet formats. I totally agree with you that they are profile specific, but I also think it is useful with examples in this draft (currently the packet formats are there for that purpose and are only included as an appendix). BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Jun 16 18:32:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06794 for ; Mon, 16 Jun 2003 18:32:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GMVpG10577 for rohc-archive@odin.ietf.org; Mon, 16 Jun 2003 18:31:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GMVpm10574 for ; Mon, 16 Jun 2003 18:31:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06782 for ; Mon, 16 Jun 2003 18:31:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S2Tl-0007ex-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 18:29:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S2Tl-0007eu-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 18:29:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGx2a18196; Mon, 16 Jun 2003 12:59:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGwZm18169 for ; Mon, 16 Jun 2003 12:58:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20921 for ; Mon, 16 Jun 2003 12:58:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RxHG-00043Q-00 for rohc@ietf.org; Mon, 16 Jun 2003 12:56:18 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19RxHG-00043G-00 for rohc@ietf.org; Mon, 16 Jun 2003 12:56:18 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 17:58:03 +0100 Message-ID: From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Subject: RE: [rohc] Context replication as a separate document? Date: Mon, 16 Jun 2003 17:57:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > In general, I think that a good overall structure for ROHC-TCP > > would be the following: > > > > * 1 draft containing the TCP-specific portion of the profile. > > > > * 1 or more drafts containing protocol-independent mechanisms, > > which we might want to reuse for different ROHC profiles. > > Yes, and I guess context replication is a mechanism that might > be reused in the future. That is why I personally believe it > makes sense to keep it separate. Especially the background and > analysis is useful not to repeat in new documents. Agreed! > > The packet formats for context replication are always specific > > to a particular profile, so I don't see any value in publishing > > them separately from the remainder of the packet formats. > > I totally agree with you that they are profile specific, but I > also think it is useful with examples in this draft (currently > the packet formats are there for that purpose and are only > included as an appendix). But the actual, normative IR-REPLICATE packet formats would go in the ROHC-TCP draft instead? Do you think there's any chance of reaching consensus on at least some initial IR-REPLICATE packets (CO packets too, come to think of it) that we could then include in an updated ROHC-TCP draft before Vienna? It would be really nice to fill in these gaps, as we'd then have a complete, working proposal for a TCP compression profile... Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Jun 16 23:04:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14016 for ; Mon, 16 Jun 2003 23:04:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H340Z29329 for rohc-archive@odin.ietf.org; Mon, 16 Jun 2003 23:04:00 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H340m29325 for ; Mon, 16 Jun 2003 23:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13994 for ; Mon, 16 Jun 2003 23:03:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S6j7-0001rE-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 23:01:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S6j7-0001rB-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 23:01:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEs1a08819; Mon, 16 Jun 2003 10:54:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GErCm08791 for ; Mon, 16 Jun 2003 10:53:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16945 for ; Mon, 16 Jun 2003 10:53:08 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RvJv-0003At-00 for rohc@ietf.org; Mon, 16 Jun 2003 10:50:55 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19RvJu-0003Aq-00 for rohc@ietf.org; Mon, 16 Jun 2003 10:50:54 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GEr8126769 for ; Mon, 16 Jun 2003 09:53:08 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 09:53:06 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 07:52:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Clarification on LSB encoding Date: Mon, 16 Jun 2003 09:52:56 -0500 Message-ID: Thread-Topic: [rohc] Clarification on LSB encoding Thread-Index: AcMyP+jUjr5imLrcSh2nV0mTlv5taQB1QWJA To: Cc: , X-OriginalArrivalTime: 16 Jun 2003 14:52:57.0814 (UTC) FILETIME=[F99B5F60:01C33416] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GErCm08793 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Vishal, The assignment of P value for SN is mainly based on the possible length of SN bits in various compressed headers (see below). Namely, it allows 4-bit and 6-bit SN to handle misordering (duplicate packets or -1 change in SN). Note that there is no packet format that can carry 5-bit SN. SN bits Packet Type --------------------------- 4 bits UO-0, UO-1* 6 bits R-0, R-1*, UOR-2* 7 bits R-0-CRC (more SN bits can be carried with extensions for type 1 and 2) BR Zhigang > -----Original Message----- > From: ext vkatyal@hss.hns.com [mailto:vkatyal@hss.hns.com] > Sent: June 14, 2003 01:37 AM > To: Liu Zhigang.C (NRC/Dallas) > Cc: mapawar@hss.hns.com; rohc@ietf.org > Subject: RE: [rohc] Clarification on LSB encoding > > > > > > > > Dear zhigang, > > Thanks for the response. Please provide the detailed analysis > of the query. > > Refer to the table below > SN p interval Comment > 4 1 vref-1,vref + (2^k -1) -1 > (left shift) > 5 0 vref,vref+(2^k-1) (no shift) > 6 1 vref-1,vref + (2^k -1) -1 > (left shift) > 7 3 vref-3,vref + (2^k -1) -3 > (left shift) > > When we are using 4 bit compressed header (CH for SN, the > value of p is 1 > which implies that there is a left shift in the > interpretation interval , > where as in case of 5 bit CH p comes out to be 0, which > means there is no > shift in the interval. Considering SN=6 , p will be 1, again > there is a > left shift in interval. Now this to and fro movement is > insuring correct > encoding of misordered packets, How ? > > What is the reason behind choosing 4 and 5 in section given > for calculation > of p. > Please elaborate on this concept. > > regards, > Vishal > > > > > > > > > zhigang.c.liu@nokia.com@ietf.org on 06/14/2003 12:12:39 AM > > Sent by: rohc-admin@ietf.org > > > To: Madhusudan Pawar/HSS@HSS, > cc: > > Subject: RE: [rohc] Clarification on LSB encoding > > > > ################################################################## > > SN: The compressed RTP Sequence Number. > > > > Compressed with W-LSB. The interpretation intervals, > > see section > > 4.5.1, are defined as follows: > > > > p = 1 if bits(SN) <= 4 > > p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 > > ################################################################## > > > > How p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 is devised ? > > Hi Madhusudan, > > That means p=0 if bits(SN)=5, p=1 if bits(SN)=6, and so on. > I.e., value of p depends on the number of SN bits carried in > a compressed header. The rational is that with more SN bits > (and thus larger compressed header), we want to be able to > encode even misordered (before compressor) RTP packets. > > BR, > Zhigang > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Jun 16 23:37:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15015 for ; Mon, 16 Jun 2003 23:37:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H3b3I31853 for rohc-archive@odin.ietf.org; Mon, 16 Jun 2003 23:37:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H3asm31845 for ; Mon, 16 Jun 2003 23:36:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15003 for ; Mon, 16 Jun 2003 23:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S7Es-00028L-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 23:34:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S7Es-00028I-00 for rohc-web-archive@ietf.org; Mon, 16 Jun 2003 23:34:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLC1a05256; Mon, 16 Jun 2003 17:12:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLBfm05237 for ; Mon, 16 Jun 2003 17:11:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02975 for ; Mon, 16 Jun 2003 17:11:38 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S1EC-0006zL-00 for rohc@ietf.org; Mon, 16 Jun 2003 17:09:24 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19S1EB-0006zI-00 for rohc@ietf.org; Mon, 16 Jun 2003 17:09:23 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GLBc115673 for ; Mon, 16 Jun 2003 16:11:38 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 16:11:37 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 16:11:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] question: default slope for TS for Tsc = 0 or 1 Date: Mon, 16 Jun 2003 16:11:28 -0500 Message-ID: Thread-Topic: [rohc] question: default slope for TS for Tsc = 0 or 1 Thread-Index: AcMzNnTvA4yRyLScSHGdryVcqLV14QBD/rXA To: , X-OriginalArrivalTime: 16 Jun 2003 21:11:28.0993 (UTC) FILETIME=[DA864510:01C3344B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GLBfm05238 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Alan, Both are correct. But perhaps the first one needs clarification. > If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before > compression (see section 4.5.3), and default-slope(TS) = 1. This is intended to say that the default-slope of TS *after* scaling is 1. I.e., every increase of 1 for SN means an increase of 1 for scaled TS. > If value(Tsc) = 0, the Timestamp value is compressed as-is, and > default-slope(TS) = value(TS_STRIDE). Since TS is not scaled, the default slope (w.r.t. SN) of TS is the value of TS_STRIDE, which is 1 by default (section 5.7.5.2). (I see you already figured this out yourself.) BR, Zhigang > -----Original Message----- > From: ext Alan Kennington [mailto:ak.rohc@topology.org] > Sent: June 15, 2003 05:20 AM > To: ROHC mailing list > Subject: [rohc] question: default slope for TS for Tsc = 0 or 1 > > > On page 75 of RFC 3095, section 5.7, there's this: > > ====================================================== > TS: The compressed RTP Timestamp value. > > If value(TIME_STRIDE) > 0, timer-based compression of the RTP > Timestamp is used (see section 4.5.4). > > If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before > compression (see section 4.5.3), and default-slope(TS) = 1. > > If value(Tsc) = 0, the Timestamp value is compressed as-is, and > default-slope(TS) = value(TS_STRIDE). > ====================================================== > > This doesn't seem right to me. > Surely if Tsc = 1, then default-slope(TS) = value(TS_STRIDE), and > if Tsc = 0, then default-slope(TS) = 1. > > Is this an error? Or have I misunderstood something? > There's nothing on this in the Implementer's guide. > > Cheers, > Alan Kennington. > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Jun 17 01:08:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17098 for ; Tue, 17 Jun 2003 01:08:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H58TD06962 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 01:08:29 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H58Tm06959 for ; Tue, 17 Jun 2003 01:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17091 for ; Tue, 17 Jun 2003 01:08:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S8fb-0002eH-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 01:06:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S8fa-0002eE-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 01:06:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGa2a16350; Mon, 16 Jun 2003 12:36:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGZ7m16307 for ; Mon, 16 Jun 2003 12:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20111 for ; Mon, 16 Jun 2003 12:35:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RwuZ-0003rj-00 for rohc@ietf.org; Mon, 16 Jun 2003 12:32:51 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19RwuY-0003rg-00 for rohc@ietf.org; Mon, 16 Jun 2003 12:32:50 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 17:35:04 +0100 Message-ID: From: "Price, Richard" To: "'Ghyslain Pelletier'" , "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Mon, 16 Jun 2003 17:35:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5GGa2a16350 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H58Tm06959 Content-Transfer-Encoding: 8bit Hi, I've added a few comments inline on the ROHC-TCP issues not related to context replication. One issue that isn't mentioned below is the packet formats themselves (i.e. the CO packets and the IR-REPLICATE packets). This is the last major gap in the ROHC-TCP profile - it would be great if we could fill it in before Vienna, as we'd then have enough to offer a real, working TCP compression scheme... For the CO packets, we've made an initial proposal in: http://www.ietf.org/internet-drafts/draft-price-rohc-tcp-packet-formats-00.t xt The draft lists the packet formats in both ROHC-FN form and box notation form, so we can discuss the formats themselves without worrying about how they're documented. For the IR-REPLICATE packets there are currently two proposals - one using indicator flags in the context replication draft, and one using indicator codes in: http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01523.html If anyone has comments on either of the above, they would be much appreciated! Regards, Richard > For the TCP profile to move forward, I have tried to summarize some of > the topics that require further discussions on the mailing list: > > 1) Packet formats for ROHC-TCP, two alternatives: > > o Use ROHC-FN, and how to include the packet formats in the > normative part of the TCP draft, or; > o Use box or list notation with corresponding normative text > describing how to encode and decode each field in the header, > as in RFC-3095. As well as deciding how to notate the TCP packet formats, we actually need to design them in the first place ;-) > 2) Context replication (See the separate draft) > > 3) IR/IR-DYN format for ROHC-TCP > > The content of Section 5.5.1 is a suggestion from the editor, for > the purpose of providing grounds for discussions. This section does > not represent a consensus and the following needs to be addressed: > > o Should we use static and dynamic chains, as in 3095? The chain-based approach might be worth updating for ROHC-TCP, as there is a lot of scope for compressing the Next Header/Kind fields that indicate which items are present in the chain. At a minimum, I think we should replace the Next Header/Kind fields from the more common TCP options and IP extension headers with shorter equivalents (e.g. there are 7 common TCP options, so it's enough to send a 3-bit indicator rather than the entire Kind field in full). More aggressive compression is possible, but we'd need to discuss whether we actually need it or not. > o Compression of TCP options for IR/IR-DYN We have quite a lot of flexibility here, depending on how aggressive we want to make the compression. The proposed IR(-DYN) packet formats in keep things pretty simple for the TCP options. We compress the "obvious" fields that can always be inferred at the decompressor, such as the Length fields in fixed-length options, but fields with more complex behaviour are always sent uncompressed. > o Compression of other TCP fields in IR/IR-DYN: > - "data offset" is redundant Definitely worth compressing the Data Offset, as this is guaranteed to work for all (valid) TCP packets. So we don't need any additional packet formats... > - "IP protocol" can be derived from the profile number Again, we should definitely do this, because it doesn't cost any extra packet formats. > - "IP version" -> only two possible values, only one > bit is required. Only saves 3 bits, but costs nothing, so let's go for it... > - "TTL", particularly when compressing over the first hop Not sure about this one - would be useful for short-lived TCP flows, but needs at least one additional packet format (to send the TTL in full, just in case it can't be compressed for whatever reason). > - "MSN", could be LSB coded In the IR(-DYN) packets we can't use LSB encoding for the MSN because we don't have a value in the context. However, if we want more aggressive compression than just sending the MSN in full, we could potentially use an encoding method which we call "irregular_padded". It works like LSB encoding, except that instead of getting the MSBs from the context, the decompressor assumes that they are 0 instead. This allows us to compress small values of the MSN down to a few bits right from the first IR packet. > 4) Master Sequence Number (MSN) > o initialization of MSN (0?) I think that the most flexible solution would be to let the compressor choose the initial value for the MSN, as it doesn't cause any interoperability problems to initialise the MSN to a value other than 0. Of course, the packet formats may influence this decision (e.g. by encoding small values of the MSN more efficiently than large values). > o compression of MSN within the packet format (LSB coded?) In the CO packets we can compress the MSN using LSB encoding (how many LSBs to send in each packet format is an open issue, which is discussed further in ). In the IR(-DYN) packets we can't use LSB encoding, but we can use "irregular_padded" encoding instead (see above). > So please feel very welcome to jump into any of these questions. It > would be good to be capable of moving forward rapidly so that a new > update can be generated in time for the Vienna meeting. Thanks! > > Regards, > > /Ghyslain > > Ghyslain Pelletier, Dipl. Ing. > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit > > Ericsson AB, Laboratoriegränd 11 > Box 920, S-97128 Luleå, SWEDEN > Phone : +46 (0) 920 20 24 32 > Mobile: +46 (0) 70 609 27 73 > Ghyslain.Pelletier@epl.ericsson.se > http://www.ericsson.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 mailnull@www1.ietf.org Tue Jun 17 05:17:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04441 for ; Tue, 17 Jun 2003 05:17:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H9GXh09796 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 05:16:33 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9GWm09793 for ; Tue, 17 Jun 2003 05:16:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04432 for ; Tue, 17 Jun 2003 05:16:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SCXe-0004Ij-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 05:14:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SCXd-0004Ig-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 05:14:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H6X1a25430; Tue, 17 Jun 2003 02:33:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H6WPm25367 for ; Tue, 17 Jun 2003 02:32:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00600 for ; Tue, 17 Jun 2003 02:32:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S9yp-0003HB-00 for rohc@ietf.org; Tue, 17 Jun 2003 02:30:07 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19S9yo-0003F1-00 for rohc@ietf.org; Tue, 17 Jun 2003 02:30:06 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H6WLw2010613; Tue, 17 Jun 2003 08:32:21 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG2C0ZB; Tue, 17 Jun 2003 08:34:08 +0200 Received: by lms001.lu.erisoft.se id IAA26917; Tue, 17 Jun 2003 08:32:16 +0200 (MET DST) Message-ID: <3EEEB627.9151FFD2@epl.ericsson.se> Date: Tue, 17 Jun 2003 08:33:11 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tommy Lundemo CC: rohc@ietf.org Subject: Re: [rohc] Mode transitions (was: (no subject)) References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id IAA26917 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H6WQm25368 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5H6X1a25430 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H9GWm09793 Content-Transfer-Encoding: 8bit Tommy Lundemo wrote: > > Hi all! > > Would it be useful to introduce means for the compressor to reject a > mode change? That's an interesting question. I am also of the opinion that it would be useful to allow a compressor to decline a decompressor request for a mode transition. Right now the way RFC-3095 is written, mode changes are entirely a decompressor decision (why so?). > It seems like all the mode changes that requires the compressor to > send an IR/IR-DYN/UOR-2 packet could have used use the reserved bit > pattern for mode, to reject a mode change. This seems to be a potential approach. Some minor additional logic would also have to be introduced with respect to the parameters C_MODE, C_TRANS, D_MODE and D_TRANS of section 5.6.1 for the relevant transitions. > This could give more flexibility to ROHC implementations where > either O or R mode does not make sense to use. > > Is there any specific reason why the compressor is not allowed > to have an opinion in the mode changing procedure? > > Best Regards, > Tommy Lundemo > > ------------------------------------------- > Effnet AB http://www.effnet.com > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Jun 17 08:36:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10411 for ; Tue, 17 Jun 2003 08:36:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HCZkP23411 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 08:35:46 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HCZjm23408 for ; Tue, 17 Jun 2003 08:35:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10408 for ; Tue, 17 Jun 2003 08:35:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SFeR-0005bs-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 08:33:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SFeR-0005bh-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 08:33:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9U1a10282; Tue, 17 Jun 2003 05:30:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9TQm10246 for ; Tue, 17 Jun 2003 05:29:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04671 for ; Tue, 17 Jun 2003 05:29:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SCk8-0004Mt-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:27:08 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19SCk7-0004Mm-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:27:08 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 10:28:53 +0100 Message-ID: From: "Surtees, Abigail" To: "'rohc@ietf.org'" Date: Tue, 17 Jun 2003 10:28:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Sigcomp Nack Draft -01 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi All, Here are some comments on the Nack draft. Section 2.1 Last sentence: The change in behavior for a reliable transport no longer involves re-transmitting the message so why would you need to be able to retrieve a plain-text version of the message? Section 2.3.2 If the underlying TCP connection has caused SigComp to fail, can it be trusted to transmit a NACK? Section 2.4 This mechanism is a good idea. It gives a definitive way for a compressor to find out if the other end supports the nack scheme. The probe idea is also possible but does have the limitations mentioned so I don't think is worth having to the draft. Appendix B: Changes Moving NACK parameters: Isn't it impossible to have standalone feedback messages (other than NACKs) because there is no way to determine for which compartment the ACK is unless there is a message to go with it? I don't think there is any problem with the message format itself. Best regards, Abbie Abbie Surtees Engineer Internet Applications and Mobility Roke Manor Research Ltd Tel: +44 (0) 1794 833131 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Jun 17 10:39:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19960 for ; Tue, 17 Jun 2003 10:39:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HEcqf01794 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 10:38:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEcqm01791 for ; Tue, 17 Jun 2003 10:38:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19940 for ; Tue, 17 Jun 2003 10:38:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHZZ-000065-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 10:36:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SHZY-000061-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 10:36:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HCb1a23552; Tue, 17 Jun 2003 08:37:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HCaqm23500 for ; Tue, 17 Jun 2003 08:36:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10441 for ; Tue, 17 Jun 2003 08:36:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SFfV-0005cG-00 for rohc@ietf.org; Tue, 17 Jun 2003 08:34:33 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SFfV-0005cD-00 for rohc@ietf.org; Tue, 17 Jun 2003 08:34:33 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HCbdcv013559 for ; Tue, 17 Jun 2003 14:37:39 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Jun 2003 14:36:42 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Tue, 17 Jun 2003 14:36:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, > One issue that isn't mentioned below is the packet formats > themselves (i.e. the CO packets and the IR-REPLICATE packets). > This is the last major gap in the ROHC-TCP profile - it would > be great if we could fill it in before Vienna, as we'd then > have enough to offer a real, working TCP compression scheme... > > For the CO packets, we've made an initial proposal in: > > draft-price-rohc-tcp-packet-formats-00.txt > > The draft lists the packet formats in both ROHC-FN form and > box notation form, so we can discuss the formats themselves > without worrying about how they're documented. I do not think our problem here is in the details, but rather how to put the formats in ROHC TCP. If we had known that, we could easily include a first-attempt format set and then improved it, but I do not think that makes sense without first agreeing on the format documentation approach. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Jun 17 11:14:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21758 for ; Tue, 17 Jun 2003 11:14:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HFDha04647 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 11:13:43 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFDhm04644 for ; Tue, 17 Jun 2003 11:13:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21735 for ; Tue, 17 Jun 2003 11:13:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SI7J-0000Xk-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 11:11:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SI7I-0000Xh-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 11:11:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9W2a10506; Tue, 17 Jun 2003 05:32:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9Vmm10470 for ; Tue, 17 Jun 2003 05:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04727 for ; Tue, 17 Jun 2003 05:31:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SCmQ-0004Ne-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:29:30 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SCmP-0004NZ-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:29:29 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H9Wacv016746; Tue, 17 Jun 2003 11:32:36 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8SRKZ; Tue, 17 Jun 2003 11:32:05 +0200 Received: by lms001.lu.erisoft.se id LAA00027; Tue, 17 Jun 2003 11:31:41 +0200 (MET DST) Message-ID: <3EEEE033.6F5CD665@epl.ericsson.se> Date: Tue, 17 Jun 2003 11:32:35 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" CC: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Subject: Re: [rohc] Context replication as a separate document? References: 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-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Price, Richard" wrote: [snip] > > > The packet formats for context replication are always specific > > > to a particular profile, so I don't see any value in publishing > > > them separately from the remainder of the packet formats. > > > > I totally agree with you that they are profile specific, but I > > also think it is useful with examples in this draft (currently > > the packet formats are there for that purpose and are only > > included as an appendix). > > But the actual, normative IR-REPLICATE packet formats would go in > the ROHC-TCP draft instead? Yes, that's my opinion. As L.-E pointed out, the appendix in the ROHC-CR draft was only to illustrate a possibility and generate a discussion. It was meant to be removed from that draft at a later stage and the formats resulting from the discussion to be included in the relevant document (e.g. ROHC-TCP draft). > Do you think there's any chance of > reaching consensus on at least some initial IR-REPLICATE packets > (CO packets too, come to think of it) that we could then include in > an updated ROHC-TCP draft before Vienna? This is my hope too. However, I would still like to have the discussion about how we are planning to document those, so I find it doubtful that we will succeed in including them in the draft before Vienna. > It would be really nice to > fill in these gaps, as we'd then have a complete, working proposal > for a TCP compression profile... > > 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 mailnull@www1.ietf.org Tue Jun 17 11:33:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22741 for ; Tue, 17 Jun 2003 11:33:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HFWZN05568 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 11:32:35 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFWZm05565 for ; Tue, 17 Jun 2003 11:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22700 for ; Tue, 17 Jun 2003 11:32:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SIPZ-0000nr-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 11:30:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SIPZ-0000no-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 11:30:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8V2a05586; Tue, 17 Jun 2003 04:31:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8UJm05541 for ; Tue, 17 Jun 2003 04:30:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03697 for ; Tue, 17 Jun 2003 04:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBov-000467-00 for rohc@ietf.org; Tue, 17 Jun 2003 04:28:01 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19SBou-00045y-00 for rohc@ietf.org; Tue, 17 Jun 2003 04:28:01 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 09:29:46 +0100 Message-ID: From: "Surtees, Abigail" To: "'rohc@ietf.org'" Date: Tue, 17 Jun 2003 09:29:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Sigcomp Implementer's Guide Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi All, There have been some suggestions for additions to the implementer's guide so here's the proposed text. Any comments and other additions gratefully received. I'm planning to resubmit the draft before the -0n deadline so would appreciate comments before the end of this week please - this gives time to make changes and agree them on the list before the deadline. Clarification that STATE-FREE is compartment specific: 2nd paragraph added to section 3.2: "The STATE-FREE instruction can only free state in the compartment that corresponds to the message being decompressed. Attempting to free state either from another compartment or that is locally available has no effect." Summary of the outcome of discussion about dynamic DMS and SMS updates: "8. Dynamic Update of Resources Decompressor resources such as SMS and DMS can be dynamically updated at the compressor by use of the SMS and DMS bits in returned parameters feedback (section 9.4.9). Changing resources dynamically (apart from initial advertisements for each compartment) is not expected to happen very often. If additional resources are advertised to a compressor then it is up to the implementation at the compressor whether or not to make use of these resources. For example, if the decompressor advertises 8k SMS but the compressor only has 4k SMS then the compressor may choose not to use the extra 4k (e.g. in order to monitor state saved at the decompressor). In this case, there is no synchronisation problem. The compressor must not use more than the most recently advertised resources. Note that the compressor SMS is unofficial (enables compressor to monitor decompressor state) and is separate from the SMS advertised by the decompressor. Reducing the resources has potential synchronisation issues and so should not be done unless absolutely necessary. If this is the case then the memory should not be reclaimed until the remote endpoint has acknowledged the message sent with the advertisement. If state must be deleted to accommodate a reduction in SMS then both endpoints should delete it according to the state retention priority (section 6.2). The compressor should use up to the amount of resources most recently advertised." There was also a suggestion about clarification that state too large for the available SMS in shared mode should be truncated (and the hash computed appropriately). IMHO this is no different from any other state that is too large and is clear in RFC 3320. Does anyone think this is a useful clarification to include? Best regards, Abbie Abbie Surtees Engineer Internet Applications and Mobility Roke Manor Research Ltd Tel: +44 (0) 1794 833131 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Jun 17 11:37:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23028 for ; Tue, 17 Jun 2003 11:37:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HFbVv06361 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 11:37:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFbVm06358 for ; Tue, 17 Jun 2003 11:37:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22957 for ; Tue, 17 Jun 2003 11:37:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SIUL-0000sw-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 11:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SIUK-0000st-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 11:35:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9W3a10514; Tue, 17 Jun 2003 05:32:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9Vvm10479 for ; Tue, 17 Jun 2003 05:31:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04730 for ; Tue, 17 Jun 2003 05:31:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SCmZ-0004Nk-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:29:39 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SCmY-0004Nh-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:29:38 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H9Wjcv016789 for ; Tue, 17 Jun 2003 11:32:45 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8SRNN; Tue, 17 Jun 2003 11:32:14 +0200 Received: by lms001.lu.erisoft.se id LAA00030; Tue, 17 Jun 2003 11:31:50 +0200 (MET DST) Message-ID: <3EEEE03C.951CBC6C@epl.ericsson.se> Date: Tue, 17 Jun 2003 11:32:44 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "rohc@ietf.org" Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id LAA00030 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H9Vvm10480 Subject: [rohc] Packets formats for ROHC-TCP and ROHC-FN Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5H9W3a10514 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HFbVm06358 Content-Transfer-Encoding: 8bit ROHCers, With consideration for the ROHC-TCP profile, in order to make a decision regarding the packet formats I feel that we need to get the discussion around the formal notation moving again. To this objective, I'd like to know what the consensus is regarding the following: * Nature of the Formal Notation o The precise scope and purpose of the FN o The requirements and objectives of the FN. What should it exactly achieve? o Do we need to have a draft to list scope, purpose, requirements and motivations for the FN to help us better understand how to proceed with this item? * Contents of the FN draft The FN draft is written with ROHC-TCP in mind in the sense that the set of encoding methods documented contains exactly the set of methods proposed by the authors for use with the TCP profile. However, the text itself would apply to other profiles if this set would be augmented. o Should the FN be generic enough so that it can be reused easily when defining new profiles, or shold it be specific to ROHC-TCP only? * Status of the FN - where do we go from now? It seems that the FN cannot progress unless there are some more discussions on the mailing list regarding at least the above points. From the author's perspective, the work is complete and only clarifications and improvements are needed, however I am still unclear on how to make all the pieces fit together, at least concerning ROHC-TCP. o How to go forward with ROHC-TCP and the FN? I think it would be useful at this point to discuss the above. Regards, /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 14:04:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28921 for ; Tue, 17 Jun 2003 14:04:20 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HI3qn08022 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 14:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus with esmtp (Exim 4.20) id 19SJRb-0003DI-D6 for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 12:36:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25667 for ; Tue, 17 Jun 2003 12:36:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SJPM-0001aZ-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 12:34:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SJPM-0001aW-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 12:34:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEx1a02837; Tue, 17 Jun 2003 10:59:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEwEm02785 for ; Tue, 17 Jun 2003 10:58:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20936 for ; Tue, 17 Jun 2003 10:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHsJ-0000Kz-00 for rohc@ietf.org; Tue, 17 Jun 2003 10:55:55 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19SHsI-0000Kw-00 for rohc@ietf.org; Tue, 17 Jun 2003 10:55:54 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 15:58:09 +0100 Message-ID: From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'Ghyslain Pelletier'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Tue, 17 Jun 2003 15:58:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > One issue that isn't mentioned below is the packet formats > > themselves (i.e. the CO packets and the IR-REPLICATE packets). > > This is the last major gap in the ROHC-TCP profile - it would > > be great if we could fill it in before Vienna, as we'd then > > have enough to offer a real, working TCP compression scheme... > > > > For the CO packets, we've made an initial proposal in: > > > > draft-price-rohc-tcp-packet-formats-00.txt > > > > The draft lists the packet formats in both ROHC-FN form and > > box notation form, so we can discuss the formats themselves > > without worrying about how they're documented. > > I do not think our problem here is in the details, but rather > how to put the formats in ROHC TCP. If we had known that, we > could easily include a first-attempt format set and then improved > it, but I do not think that makes sense without first agreeing > on the format documentation approach. In this case, should the ROHC-TCP draft contain proposals for the IR and IR-DYN packets? Is it really ok to include these without first agreeing on the format documentation approach? Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 14:15:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29684 for ; Tue, 17 Jun 2003 14:15:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIEjK12053 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 14:14:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus with esmtp (Exim 4.20) id 19SJqs-0003up-4B for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26344 for ; Tue, 17 Jun 2003 13:02:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SJod-0001kl-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 13:00:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SJoc-0001ki-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 13:00:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDE1a27337; Tue, 17 Jun 2003 09:14:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDDDm27317 for ; Tue, 17 Jun 2003 09:13:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13147 for ; Tue, 17 Jun 2003 09:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SGEg-0006RE-00 for rohc@ietf.org; Tue, 17 Jun 2003 09:10:54 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SGEf-0006RB-00 for rohc@ietf.org; Tue, 17 Jun 2003 09:10:54 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HDE1cv020097 for ; Tue, 17 Jun 2003 15:14:01 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Jun 2003 15:13:04 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Date: Tue, 17 Jun 2003 15:12:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] ROHC chair suffering from car crash injuries Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Dear ROHCers, Three weeks ago I was involved in a car accident, and my neck got hurt. During the weeks after the accident, I have tried to work as usual, but now it has become clear that I will have to take a time-out and give myself time to recover. Therefore, I am currently working only about (at most) one hour each day, trying to keep up with the most important things, especially the ROHC list. However, I thought you all deserved an explanation why I might not respond as usual to your requests and questions, and let you be aware of the situation. I still plan (and hope) to go to Vienna, but do not expect too much from me during the period from now to then. I just wanted you all to be aware of the situation, and I'll do my best to recover as soon as possible. Regards, /L-E -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 14:15:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29749 for ; Tue, 17 Jun 2003 14:15:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFG112187 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus with esmtp (Exim 4.20) id 19SJu2-0003wB-S6 for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:05:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26408 for ; Tue, 17 Jun 2003 13:05:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SJro-0001m8-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 13:03:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SJrn-0001m4-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 13:03:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HCg1a24744; Tue, 17 Jun 2003 08:42:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HCfBm24702 for ; Tue, 17 Jun 2003 08:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11088 for ; Tue, 17 Jun 2003 08:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SFjh-0005n3-00 for rohc@ietf.org; Tue, 17 Jun 2003 08:38:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SFjg-0005mw-00 for rohc@ietf.org; Tue, 17 Jun 2003 08:38:52 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HCf8G5016716; Tue, 17 Jun 2003 14:41:08 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Jun 2003 14:41:02 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Ghyslain Pelletier (EAB)" , "Price, Richard" Cc: "Rohc (E-mail)" Subject: RE: [rohc] Context replication as a separate document? Date: Tue, 17 Jun 2003 14:40:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Ghyslain, > > > > The packet formats for context replication are always specific > > > > to a particular profile, so I don't see any value in publishing > > > > them separately from the remainder of the packet formats. > > > > > > I totally agree with you that they are profile specific, but I > > > also think it is useful with examples in this draft (currently > > > the packet formats are there for that purpose and are only > > > included as an appendix). > > > > But the actual, normative IR-REPLICATE packet formats would go in > > the ROHC-TCP draft instead? > > Yes, that's my opinion. As L.-E pointed out, the appendix in > the ROHC-CR draft was only to illustrate a possibility and > generate a discussion. It was meant to be removed from that > draft at a later stage and the formats resulting from the > discussion to be included in the relevant document (e.g. > ROHC-TCP draft). I think there should be examples in the generic replication draft, but only as examples. So, keep them in the appendix, for now they can stay as they are and later we can maybe reduce them to one example. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 14:15:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29860 for ; Tue, 17 Jun 2003 14:15:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFPg12684 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKfW-0001W1-FD for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:54:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28337 for ; Tue, 17 Jun 2003 13:54:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKdG-0002G5-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 13:52:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKdG-0002G2-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 13:52:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HCr1a25238; Tue, 17 Jun 2003 08:53:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HCqIm25205 for ; Tue, 17 Jun 2003 08:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11958 for ; Tue, 17 Jun 2003 08:52:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SFuR-000629-00 for rohc@ietf.org; Tue, 17 Jun 2003 08:49:59 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SFuQ-000626-00 for rohc@ietf.org; Tue, 17 Jun 2003 08:49:59 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HCqEG5019443; Tue, 17 Jun 2003 14:52:14 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 17 Jun 2003 14:52:08 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Ghyslain Pelletier (EAB)" , Tommy Lundemo Cc: rohc@ietf.org Subject: RE: [rohc] Mode transitions (was: (no subject)) Date: Tue, 17 Jun 2003 14:51:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Tommy, Ghyslain, and others, > > Would it be useful to introduce means for the compressor to > > reject a mode change? > > That's an interesting question. I am also of the opinion that > it would be useful to allow a compressor to decline a > decompressor request for a mode transition. Right now the way > RFC-3095 is written, mode changes are entirely a decompressor > decision (why so?). I think this was just something we did not think of at that point in time, we just agreed that the decompressor should be the one initiating mode transitions, and we never even talked about any other options than confirmations from the compressor. However, as negotiations usually allow both sides to express their opinion, I agree with you that it seems reasonable to have such an alternative. The question is how to address this standardization-wise. We do not want to upgrade the existing profiles just to add this, I think, but let's keep it in our minds if we make new revision of profiles 1-3. Maybe it would make sense to add it to the IP profile, i.e. define the "reserved" value for the mode response in that profile. > > It seems like all the mode changes that requires the compressor to > > send an IR/IR-DYN/UOR-2 packet could have used use the reserved bit > > pattern for mode, to reject a mode change. > > This seems to be a potential approach. Some minor additional logic > would also have to be introduced with respect to the parameters > C_MODE, C_TRANS, D_MODE and D_TRANS of section 5.6.1 for the > relevant transitions. Well, not very much, basically just state how a rejected mode transition should be terminated. > > Is there any specific reason why the compressor is not allowed > > to have an opinion in the mode changing procedure? Standardization that has progressed too quickly... BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 14:15:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29864 for ; Tue, 17 Jun 2003 14:15:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFPk12756 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKml-00021e-CQ for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:02:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28778 for ; Tue, 17 Jun 2003 14:02:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKkV-0002Lo-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKkV-0002Ll-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:00:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEh3a02052; Tue, 17 Jun 2003 10:43:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEgCm02002 for ; Tue, 17 Jun 2003 10:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20074 for ; Tue, 17 Jun 2003 10:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHcm-00007p-00 for rohc@ietf.org; Tue, 17 Jun 2003 10:39:52 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19SHcj-00007B-00 for rohc@ietf.org; Tue, 17 Jun 2003 10:39:51 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 6D3648A77C; Wed, 18 Jun 2003 00:11:17 +0930 (CST) Date: Wed, 18 Jun 2003 00:11:17 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030618001117.A905@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] RFC 3095 question: TS wraparound interpretation interval Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Here's another area of RFC 3095 which seems a little unclear. Therefore I think this also deserves to be in the ROHC implementer's guide in more detail. This issue does affect interoperability, although admittedly the TS wraparound is rare. For 8 kHz timer for audio, I make it 2^32/8000/3600 = 149.13 hours. For 90 kHz video, I make it: 2^32/90000/3600 = 13.256 hours. So I guess no one's really going to notice. However, I want to know how to do it correctly. So... There are two cases where there is possible ambiguity - positive wraparound (case A) and negative wraparound (case B). Case A: vref >= vmax + p - 2^k + 2 Case B: vref <= p - 1. Here "vref" is the reference value, which is an earlier value of the scaled 32-bit TS field. "vmax" = floor((2^32 - 1)/TS-scale) is the maximum value of the scaled 32-bit TS field. Now suppose the decompressor receives the value x = (v modulo 2^k), where v is the current scaled TS field in the IP header which the compressor must transmit. Then the decompressor normally does this to recover the value of v: v = vref - p + ((x - vref + p) modulo 2^k). This value v may be greater than vmax in case A. Question 1: If the above calculation for "v" give me a number greater than vmax, is the decompressor always justified in interpreting the value of v as v = x? It seems to me logical that this must be so if I wanted an optimal protocol. In other words, if I can't interpret the value in the interpretation interval [vref - p, vmax], then I should interpret it in the interval [0, 2^k - 1], because that is what the RTP source will probably do next. Now look at case B. In this case I may have a negative wraparound because the rule v = vref - p + ((x - vref + p) modulo 2^k) may give me a negative number v < 0. Question 2: If the calculation of v by the decompressor gives a negative number in case B, am I always justified in interpreting the value v in the interval [vmax - 2^k + 1, vmax]? I see nothing about negative wraparound in RFC 3095. However, the scaled TS may go backwards even when TS = 0. It seems logical to do the same thing with negative and positive wraparounds. When I interpret ambiguous parts of RFC 3095, I always try to make an interpretation which gives me the best protocol. But this is not necessarily the same as everyone else's interpretation. I would like to propose that the above TS wraparound rules be included in the ROHC implementer's guide. What is the procedure for proposing changes to the ROHC implementer's guide? Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 15:23:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05971 for ; Tue, 17 Jun 2003 15:23:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJNGS11010 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL6G-0003te-8H for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:22:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00717 for ; Tue, 17 Jun 2003 14:22:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SL40-0002nW-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:20:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SL3z-0002nT-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:20:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFD0a04594; Tue, 17 Jun 2003 11:13:00 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFCCm04539 for ; Tue, 17 Jun 2003 11:12:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21675 for ; Tue, 17 Jun 2003 11:12:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SI5r-0000X3-00 for rohc@ietf.org; Tue, 17 Jun 2003 11:09:55 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SI5q-0000X0-00 for rohc@ietf.org; Tue, 17 Jun 2003 11:09:54 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HFD1cv007064; Tue, 17 Jun 2003 17:13:01 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8VK05; Tue, 17 Jun 2003 17:12:31 +0200 Received: by lms001.lu.erisoft.se id RAA07249; Tue, 17 Jun 2003 17:12:06 +0200 (MET DST) Message-ID: <3EEF2FFB.17709608@epl.ericsson.se> Date: Tue, 17 Jun 2003 17:12:59 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" CC: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: Re: [rohc] ROHC-TCP: Update and some topics to be discussed References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id RAA07249 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HFCCm04540 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5HFD0a04594 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05971 Richard, The editor added formats for IR and IR-DYN in the ROHC-TCP draft because he unfortunately hadn't realized that you also had a proposal for those and was under the belief that the IRs would follow the same structure as in RFC-3095. The idea was also to generate discussions on those to at least move forward with IR formats, while waiting for the CO packets. I should have added an author's note to this effect in the draft. Mea culpa. Obviously the IRs will be adjusted based on agreements on the list. On the other hand I do agree with Lars-Erik that the issue on how to document the packet formats is the pressing issue. While this does not prevent us to comment on the formats that you have suggested, it does make it hard to include them to the ROHC-TCP draft at this point. /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com "Price, Richard" wrote: > > > > One issue that isn't mentioned below is the packet formats > > > themselves (i.e. the CO packets and the IR-REPLICATE packets). > > > This is the last major gap in the ROHC-TCP profile - it would > > > be great if we could fill it in before Vienna, as we'd then > > > have enough to offer a real, working TCP compression scheme... > > > > > > For the CO packets, we've made an initial proposal in: > > > > > > draft-price-rohc-tcp-packet-formats-00.txt > > > > > > The draft lists the packet formats in both ROHC-FN form and > > > box notation form, so we can discuss the formats themselves > > > without worrying about how they're documented. > > > > I do not think our problem here is in the details, but rather > > how to put the formats in ROHC TCP. If we had known that, we > > could easily include a first-attempt format set and then improved > > it, but I do not think that makes sense without first agreeing > > on the format documentation approach. > > In this case, should the ROHC-TCP draft contain proposals for the > IR and IR-DYN packets? Is it really ok to include these without > first agreeing on the format documentation approach? > > Regards, > > Richard > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > 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. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 15:23:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06038 for ; Tue, 17 Jun 2003 15:23:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJNJZ11407 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLau-0006PG-0q for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:54:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02706 for ; Tue, 17 Jun 2003 14:54:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLYd-0003Gu-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:51:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLYc-0003Gr-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:51:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9W2a10493; Tue, 17 Jun 2003 05:32:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H9Vbm10454 for ; Tue, 17 Jun 2003 05:31:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04697 for ; Tue, 17 Jun 2003 05:31:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SCmE-0004NS-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:29:18 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SCmD-0004NP-00 for rohc@ietf.org; Tue, 17 Jun 2003 05:29:17 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5H9WNcv016700; Tue, 17 Jun 2003 11:32:23 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8SR2Q; Tue, 17 Jun 2003 11:31:52 +0200 Received: by lms001.lu.erisoft.se id LAA00022; Tue, 17 Jun 2003 11:31:27 +0200 (MET DST) Message-ID: <3EEEE025.51B438EF@epl.ericsson.se> Date: Tue, 17 Jun 2003 11:32:21 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yousuf.Saifullah@nokia.com, rohc@ietf.org, "Price, Richard" Subject: Re: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) References: <025E7DD4182874489CC2F61EE0FA19CE0139885A@daebe004.americas.nokia.com> <3EDF577F.32F2CEDE@epl.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id LAA00022 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H9Vbm10455 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5H9W2a10493 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA06038 Hi Richard and Yousouf, I have combined your questions regarding feedback with ROHC-CR in a single mail. Look for my comments in-line. Hopefully it helps clarifiying this part of the ROHC-CR draft. "Price, Richard" wrote: > Page 6: "otherwise the base context is overwritten with the new > context by the replication process." > > If we set the base context equal to the current context, is it > still the case that we need to acknowledge the base context using > a feedback packet? Not unless the overwritten context is to be used later as the base context for another replication. Since in the feedback section it is said the the decompressor should ACK a successful decompression of one or more IR-REPLICATE (including the initial sequence of IR-REPLICATE that initially overwrite the base context), then it should anyway have been acknowledged at one point and be possible to reuse later. > It might be useful to offer the IR-REPLICATE > packet as an ordinary packet format, which can be used to send > compressed headers even in the unidirectional case. I see this as a different issue than the previous comment. I think that at least the *initial sequence* (i.e. "one or more initial" in the draft) of IR-REPLICATE used to replicate a base context to initialize the context for a new flow should be acknowledged in some way. Once this is done, I don't think (I belive this is in-line with the current text) that it prevents the decompressor to request to the compressor to continue in unidirectional operation even considering the initial ACK, and that the IR-REPLICATE may still be used after that without the *need* to acknowledge it when it is received (currently a "SHOULD" in the draft). So, unless I am mistaking, the draft currently allows what your comment mentions. > Page 6: "Upon reception of a STATIC-NACK, the compressor MUST > transit back to its initial no context state and SHOULD refrain > from sending IR-REPLICATE packets using the same base context." > > How does the above interact with the robustness mechanisms of the > base context itself? For example, if the compressor continues to > use the base context and continues to receive positive ACKs in > the normal manner, is it ok to assume that the base context is > actually valid (and hence that the IR-REPLICATE packet itself is > where the error occurred)? Yes, it is ok. This is tied to the decompressor logic when using the STATIC-NACK. In the case of the IR-REPLICATE, the text in the draft means that STATIC-NACK would not be sent because of a CRC-8 failure (which verifies the integrity of the IR-REPLICATE packet itself), but because a number of consecutive decompression failures (CRC-7, used to validate the context) for IR-REPLICATE packets would have occurred. > Conversely, would it be possible for the compressor to take a > STATIC-NACK for the newly replicated context as evidence that > something is wrong with the base context? It could use this > information to influence the state machine of the base context, > e.g. by causing it to transit to a lower state. Yes, this is actually what the text in the draft says. I.e., the second paragraph in section 3.3.2 says that the decompressor invalidates a context and should send STATIC-NACK when an attempt to replicate the context fails, while the third paragraph says that if the context has been replicated successfully but IR-REPLICATE(s) are later received and failed decompression, then NACK should be sent. Or maybe I misunderstood your comment? Yousuf.Saifullah@nokia.com wrote: > > [Yousuf] I think it is possible to use STATIC-NACK for > > indicating corruption in the base context, and another NACK > > for indicating transmission error in IR-REPLICATE packet. We In my understanding, ACKs and NACKs are used to transmit information regarding the state of the context (potentially at a specific packet in the SN space), not to provide information regarding the state of the transmission. Therefore I do not really understand why there would be a need to define a new feedback option to indicate transmission error in the IR-REPLICATE packet. > > have two CRCs. 7-bit CRC covers the original uncompressed > > header and the 8-bit CRC covers the IR packet including > > static and dynamic chain (this is with the change proposed in > > my last email). If 8-bit CRC verifies integrity of IR- The extent of the coverage of the 8-bit CRC (other than the minimal coverage required by RFC-3095) is profile dependent. It would be unappropriate to define it as to include chains in this draft, unless we make context replication profile-specific. This is also in line with one of Richard's previous comment on this thread. > > REPLICATE packet header, but the 7-bit CRC failed after > > decompression, then this implies that we have a problem in > > the base context. In this case only the decompressor will > > send a STATIC-NACK indicating that the decompression failed > > due to the problem in the base context. The compressor would > > discard that base context and send IR packet. Only for the "one or more initial IR-REPLICATE packets", as currently stated in the draft. "Price, Richard" wrote: > Page 6: "Upon reception of a NACK, the compressor may assume > that the static part of the decompressor context is valid but > that the dynamic part is invalid, and take actions accordingly." > > Again, could this also be used by the compressor as evidence > that something is wrong with the base context? Not in this case. See previous comment. Yousuf.Saifullah@nokia.com wrote: > > [Yousuf] Can we solve this concern by adding IR-REPLICATE > > state between IR and CO state in the compressor state machine > > as shown below. > > > > Optimistic approach / ACK ACK > > +------>-------->------>------>---------+ +->-+ > > | Base Ctxt Avail ACK | | | > > | +----------+ +---->---->---------|| | | > > | | V | vv | v > > +----------+ +--------------+ +----------+ > > | IR State | | IR-REP State | | CO State | > > +----------+ +--------------+ +----------+ > > ^ ^ | ^ | | > > | +---<-----+ +-<-+ | > > | STATIC-NACK Timeout/NACK | > > | | > > | Timeout / NACK / STATIC-NACK | > > +-------<-------<-------<-------<--------+ > > > > I think this is also what context context replication is > > doing. Replication is a complement to the context initialization. I do not really see the relevance of adding a new state for context replication. "Price, Richard" wrote: > Page 7: "Specifically, when the decompressor fails to validate > the context following the decompression of one or more initial > IR-REPLICATE packets, it MUST invalidate the context and remain > in its initial state. In addition, the decompressor SHOULD send > a STATIC-NACK." > > This logic is fine for O-mode and B-mode, but I think that > different logic is required in the case of R-mode. From RFC 3095: > > "The decompressor SHOULD NOT send STATIC-NACK(R) when > receiving an IR packet that fails the CRC check, as the > compressor will stay in IR state and thus continue sending > IR packets until a valid ACK is received" > > The above also applies to an IR-REPLICATE packet, so the > decompressor SHOULD NOT send a STATIC-NACK in this case. In my understanding, if the CRC fails for the IR we cannot deduce anything as to the validity of the context, as the 8-bit CRC is calculated over information contained in the packet only. Thus in my understanding the text in the draft still means that in this case the decompressor would not send STATIC-NACK anyway, so in my understanding this would not conflict with respect to R-mode. Furthermore, modes are actually profile dependent, not generic to all profiles, so this draft should not go in more details regarding this in my opinion. > Page 7: "The decompressor SHOULD send an ACK when it succeeds to > validate the context as a result of the decompression of one or > more IR-REPLICATE packets." > > For R-mode, the above logic needs to be much more precisely > defined (taking into account the "Sparse ACK" mechanism). This is a profile-specific consideration, which I don't think should be elaborated in this draft if it is to remain generic or alternatively if it is to be defined for the TCP profile only. I believe a document defining revisions of profiles implementing context replication is where this should be precised, if necessary, and this is not the scope of this document. Furthermore, I consider this particular point as a general recommendation that in my understanding (R-mode experts - please correct me if I am wrong) is not in contradiction with the sparse ACK mechanism - it would fall into the "or more IR-REPLICATE packets" (first 2 or first N of a sequence, then each k packets). For a profile having R-mode, it do however agree that it would be useful to add precisions for the IR-REPLICATE with the Sparse ACK mechanism. Yousuf.Saifullah@nokia.com wrote: > - I think we can improve on failure mechanism mentioned in the > above two sections. The draft mentions that if the > decompression of IR-REPLICATE fails, the decompressor will send > STATIC NACK and the compressor MUST refrain from IR-REPLICATE, > in other words use IR packets. Moving to IR means sending more This is actually an incorrect interpretation of the text in the draft. Maybe I should try to clarify the text. The draft actually states in the second paragraph in section 3.3.2 says that the decompressor invalidates a context and should send STATIC-NACK when an attempt to replicate the context fails (first N of a sequence of IR-REPLICATE for a new flow, where N is one or more), while the third paragraph says that if the context has been replicated successfully but IR-REPLICATE(s) are later received and failed decompression, then NACK should be sent. Thus if the decompression of IR-REPLICATE fails, the decompressor may a STATIC-NACK or a NACK depending on the case. > bytes compared to IR-REPLICATE, hence degrading compression > efficiency. If the decompression has failed due to transmission > error of IR-REPLICATE (case-1), then the decompressor is > unnecessarily asking for IR. It is better to ask for the > retransmission of IR-REPLICATE and gain more compression > efficiency. Not to mention, retransmitting an already encoded > packet would be faster for the compressor. It is also possible > that the decompression has failed because of the corruption in > the base context (case-2). In case-2 we definitely want to move > to the IR packet, since there is no way to fix it without > sending full header. Case-1 would normally not trigger feedback. Case-2 would normally trigger a NACK. An additional case is when N IR-REPLICATE received (where k out of N succeed 8-bit CRC validation) would not succeed into replicating a context (7-bit CRC fails for k); this would trigger STATIC-NACK. > I'd propose that the decompressor should differentiate between > the two cases. It can be done if we increase the coverage of 8- > bit CRC (section 3.4.1.2)to cover static and dynamic chain > also. The CRC of an IR or IR-DYN covers the whole IR packet, > excluding payload (section 5.9.2 of RFC 3095). The proposed > change in 8-bit CRC is more in line with the IR and IR-DYN CRC. This would correspond to a requirement on something that is actually profile specific. The draft only put requirements on the minimal extent of the coverage for the 8-bit CRC. > The logic would work something like this: > - if 7-bit CRC failed, send STATIC-NACK This would prevent the IR-REPLICATE to be used like any other compressed packet. A failure to decompress one such packet does not necessarily means that the static part in invalid. > - if 8-bit CRC fails, send another NACK (let's call it REP- > NACK). The 8-bit CRC protects the integrity of the IR packet itself. while feedback is used to convey information regarding the state of the context. In my opinion, it would be not be proper to define a new feedback type to report a transmission error instead of considering the state of the context. > We could differentiate a REP-NACK from a regular NACK by using > feedback options in the FEEDBACK-2 format and make this option > available to other profiles besides TCP. We could have used In my opinion, this is not necessary. Also, I would be reluctant to define a new feedback option if I can avoid it. > NACK such that a NACK in response to IR-REPLICATE would ask > compressor to resend IR-REPLICATE. But it seems like that the > draft has a different use of this NACK (section 3.3.2). > Let me know if you still see a potential issues with the above. Thanks! /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 15:23:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06042 for ; Tue, 17 Jun 2003 15:23:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJNJn11434 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLbH-0006Sl-Ka for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:54:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02723 for ; Tue, 17 Jun 2003 14:54:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLZ1-0003Hi-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:52:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLZ0-0003Hf-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 14:52:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFF3a04785; Tue, 17 Jun 2003 11:15:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFEIm04708 for ; Tue, 17 Jun 2003 11:14:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21792 for ; Tue, 17 Jun 2003 11:14:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SI7s-0000YT-00 for rohc@ietf.org; Tue, 17 Jun 2003 11:12:00 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SI7r-0000YN-00 for rohc@ietf.org; Tue, 17 Jun 2003 11:11:59 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HFEFG5016077; Tue, 17 Jun 2003 17:14:15 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8VLPB; Tue, 17 Jun 2003 17:14:36 +0200 Received: by lms001.lu.erisoft.se id RAA07296; Tue, 17 Jun 2003 17:14:11 +0200 (MET DST) Message-ID: <3EEF3078.9AEF9F32@epl.ericsson.se> Date: Tue, 17 Jun 2003 17:15:04 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yousuf.Saifullah@nokia.com, "Price, Richard" , "rohc@ietf.org" Subject: Re: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id RAA07296 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HFEIm04709 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5HFF3a04785 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA06042 Richard, Yousouf, I have combined your questions regarding feedback with ROHC-CR in a single mail. Look for my comments in-line. Hopefully it helps clarifiying this part of the ROHC-CR draft. "Price, Richard" wrote: > Page 6: "otherwise the base context is overwritten with the new > context by the replication process." > > If we set the base context equal to the current context, is it > still the case that we need to acknowledge the base context using > a feedback packet? Not unless the overwritten context is to be used later as the base context for another replication. Since in the feedback section it is said the the decompressor should ACK a successful decompression of one or more IR-REPLICATE (including the initial sequence of IR-REPLICATE that initially overwrite the base context), then it should anyway have been acknowledged at one point and be possible to reuse later. > It might be useful to offer the IR-REPLICATE > packet as an ordinary packet format, which can be used to send > compressed headers even in the unidirectional case. I see this as a different issue than the previous comment. I think that at least the *initial sequence* (i.e. "one or more initial" in the draft) of IR-REPLICATE used to replicate a base context to initialize the context for a new flow should be acknowledged in some way. Once this is done, I don't think (I belive this is in-line with the current text) that it prevents the decompressor to request to the compressor to continue in unidirectional operation even considering the initial ACK, and that the IR-REPLICATE may still be used after that without the *need* to acknowledge it when it is received (currently a "SHOULD" in the draft). So, unless I am mistaking, the draft currently allows what your comment mentions. > Page 6: "Upon reception of a STATIC-NACK, the compressor MUST > transit back to its initial no context state and SHOULD refrain > from sending IR-REPLICATE packets using the same base context." > > How does the above interact with the robustness mechanisms of the > base context itself? For example, if the compressor continues to > use the base context and continues to receive positive ACKs in > the normal manner, is it ok to assume that the base context is > actually valid (and hence that the IR-REPLICATE packet itself is > where the error occurred)? Yes, it is ok. This is tied to the decompressor logic when using the STATIC-NACK. In the case of the IR-REPLICATE, the text in the draft means that STATIC-NACK would not be sent because of a CRC-8 failure (which verifies the integrity of the IR-REPLICATE packet itself), but because a number of consecutive decompression failures (CRC-7, used to validate the context) for IR-REPLICATE packets would have occurred. > Conversely, would it be possible for the compressor to take a > STATIC-NACK for the newly replicated context as evidence that > something is wrong with the base context? It could use this > information to influence the state machine of the base context, > e.g. by causing it to transit to a lower state. Yes, this is actually what the text in the draft says. I.e., the second paragraph in section 3.3.2 says that the decompressor invalidates a context and should send STATIC-NACK when an attempt to replicate the context fails, while the third paragraph says that if the context has been replicated successfully but IR-REPLICATE(s) are later received and failed decompression, then NACK should be sent. Or maybe I misunderstood your comment? Yousuf.Saifullah@nokia.com wrote: > > [Yousuf] I think it is possible to use STATIC-NACK for > > indicating corruption in the base context, and another NACK > > for indicating transmission error in IR-REPLICATE packet. We In my understanding, ACKs and NACKs are used to transmit information regarding the state of the context (potentially at a specific packet in the SN space), not to provide information regarding the state of the transmission. Therefore I do not really understand why there would be a need to define a new feedback option to indicate transmission error in the IR-REPLICATE packet. > > have two CRCs. 7-bit CRC covers the original uncompressed > > header and the 8-bit CRC covers the IR packet including > > static and dynamic chain (this is with the change proposed in > > my last email). If 8-bit CRC verifies integrity of IR- The extent of the coverage of the 8-bit CRC (other than the minimal coverage required by RFC-3095) is profile dependent. It would be unappropriate to define it as to include chains in this draft, unless we make context replication profile-specific. This is also in line with one of Richard's previous comment on this thread. > > REPLICATE packet header, but the 7-bit CRC failed after > > decompression, then this implies that we have a problem in > > the base context. In this case only the decompressor will > > send a STATIC-NACK indicating that the decompression failed > > due to the problem in the base context. The compressor would > > discard that base context and send IR packet. Only for the "one or more initial IR-REPLICATE packets", as currently stated in the draft. "Price, Richard" wrote: > Page 6: "Upon reception of a NACK, the compressor may assume > that the static part of the decompressor context is valid but > that the dynamic part is invalid, and take actions accordingly." > > Again, could this also be used by the compressor as evidence > that something is wrong with the base context? Not in this case. See previous comment. Yousuf.Saifullah@nokia.com wrote: > > [Yousuf] Can we solve this concern by adding IR-REPLICATE > > state between IR and CO state in the compressor state machine > > as shown below. > > > > Optimistic approach / ACK ACK > > +------>-------->------>------>---------+ +->-+ > > | Base Ctxt Avail ACK | | | > > | +----------+ +---->---->---------|| | | > > | | V | vv | v > > +----------+ +--------------+ +----------+ > > | IR State | | IR-REP State | | CO State | > > +----------+ +--------------+ +----------+ > > ^ ^ | ^ | | > > | +---<-----+ +-<-+ | > > | STATIC-NACK Timeout/NACK | > > | | > > | Timeout / NACK / STATIC-NACK | > > +-------<-------<-------<-------<--------+ > > > > I think this is also what context context replication is > > doing. Replication is a complement to the context initialization. I do not really see the relevance of adding a new state for context replication. "Price, Richard" wrote: > Page 7: "Specifically, when the decompressor fails to validate > the context following the decompression of one or more initial > IR-REPLICATE packets, it MUST invalidate the context and remain > in its initial state. In addition, the decompressor SHOULD send > a STATIC-NACK." > > This logic is fine for O-mode and B-mode, but I think that > different logic is required in the case of R-mode. From RFC 3095: > > "The decompressor SHOULD NOT send STATIC-NACK(R) when > receiving an IR packet that fails the CRC check, as the > compressor will stay in IR state and thus continue sending > IR packets until a valid ACK is received" > > The above also applies to an IR-REPLICATE packet, so the > decompressor SHOULD NOT send a STATIC-NACK in this case. In my understanding, if the CRC fails for the IR we cannot deduce anything as to the validity of the context, as the 8-bit CRC is calculated over information contained in the packet only. Thus in my understanding the text in the draft still means that in this case the decompressor would not send STATIC-NACK anyway, so in my understanding this would not conflict with respect to R-mode. Furthermore, modes are actually profile dependent, not generic to all profiles, so this draft should not go in more details regarding this in my opinion. > Page 7: "The decompressor SHOULD send an ACK when it succeeds to > validate the context as a result of the decompression of one or > more IR-REPLICATE packets." > > For R-mode, the above logic needs to be much more precisely > defined (taking into account the "Sparse ACK" mechanism). This is a profile-specific consideration, which I don't think should be elaborated in this draft if it is to remain generic or alternatively if it is to be defined for the TCP profile only. I believe a document defining revisions of profiles implementing context replication is where this should be precised, if necessary, and this is not the scope of this document. Furthermore, I consider this particular point as a general recommendation that in my understanding (R-mode experts - please correct me if I am wrong) is not in contradiction with the sparse ACK mechanism - it would fall into the "or more IR-REPLICATE packets" (first 2 or first N of a sequence, then each k packets). For a profile having R-mode, it do however agree that it would be useful to add precisions for the IR-REPLICATE with the Sparse ACK mechanism. Yousuf.Saifullah@nokia.com wrote: > - I think we can improve on failure mechanism mentioned in the > above two sections. The draft mentions that if the > decompression of IR-REPLICATE fails, the decompressor will send > STATIC NACK and the compressor MUST refrain from IR-REPLICATE, > in other words use IR packets. Moving to IR means sending more This is actually an incorrect interpretation of the text in the draft. Maybe I should try to clarify the text. The draft actually states in the second paragraph in section 3.3.2 says that the decompressor invalidates a context and should send STATIC-NACK when an attempt to replicate the context fails (first N of a sequence of IR-REPLICATE for a new flow, where N is one or more), while the third paragraph says that if the context has been replicated successfully but IR-REPLICATE(s) are later received and failed decompression, then NACK should be sent. Thus if the decompression of IR-REPLICATE fails, the decompressor may a STATIC-NACK or a NACK depending on the case. > bytes compared to IR-REPLICATE, hence degrading compression > efficiency. If the decompression has failed due to transmission > error of IR-REPLICATE (case-1), then the decompressor is > unnecessarily asking for IR. It is better to ask for the > retransmission of IR-REPLICATE and gain more compression > efficiency. Not to mention, retransmitting an already encoded > packet would be faster for the compressor. It is also possible > that the decompression has failed because of the corruption in > the base context (case-2). In case-2 we definitely want to move > to the IR packet, since there is no way to fix it without > sending full header. Case-1 would normally not trigger feedback. Case-2 would normally trigger a NACK. An additional case is when N IR-REPLICATE received (where k out of N succeed 8-bit CRC validation) would not succeed into replicating a context (7-bit CRC fails for k); this would trigger STATIC-NACK. > I'd propose that the decompressor should differentiate between > the two cases. It can be done if we increase the coverage of 8- > bit CRC (section 3.4.1.2)to cover static and dynamic chain > also. The CRC of an IR or IR-DYN covers the whole IR packet, > excluding payload (section 5.9.2 of RFC 3095). The proposed > change in 8-bit CRC is more in line with the IR and IR-DYN CRC. This would correspond to a requirement on something that is actually profile specific. The draft only put requirements on the minimal extent of the coverage for the 8-bit CRC. > The logic would work something like this: > - if 7-bit CRC failed, send STATIC-NACK This would prevent the IR-REPLICATE to be used like any other compressed packet. A failure to decompress one such packet does not necessarily means that the static part in invalid. > - if 8-bit CRC fails, send another NACK (let's call it REP- > NACK). The 8-bit CRC protects the integrity of the IR packet itself. while feedback is used to convey information regarding the state of the context. In my opinion, it would be not be proper to define a new feedback type to report a transmission error instead of considering the state of the context. > We could differentiate a REP-NACK from a regular NACK by using > feedback options in the FEEDBACK-2 format and make this option > available to other profiles besides TCP. We could have used In my opinion, this is not necessary. Also, I would be reluctant to define a new feedback option if I can avoid it. > NACK such that a NACK in response to IR-REPLICATE would ask > compressor to resend IR-REPLICATE. But it seems like that the > draft has a different use of this NACK (section 3.3.2). > Let me know if you still see a potential issues with the above. Thanks! /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com ** My apologies if you have received this email twice ** ** I resend it because I have been having problems ** ** with my mail server all day and some mails have ** ** disapeared - so I don't know if this mail made it ** ** already to the mailing list or not :-( ** _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jun 17 15:45:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07499 for ; Tue, 17 Jun 2003 15:45:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJiXT21770 for rohc-archive@odin.ietf.org; Tue, 17 Jun 2003 15:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMNd-0005f0-IN for rohc-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07445 for ; Tue, 17 Jun 2003 15:44:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMLP-0004B3-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 15:42:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SMLO-0004B0-00 for rohc-web-archive@ietf.org; Tue, 17 Jun 2003 15:42:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SM3p-00037G-PG; Tue, 17 Jun 2003 15:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLPg-0005PT-E0 for rohc@optimus.ietf.org; Tue, 17 Jun 2003 14:42:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02164 for ; Tue, 17 Jun 2003 14:42:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLNQ-00037Y-00 for rohc@ietf.org; Tue, 17 Jun 2003 14:40:16 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19SLNP-00037V-00 for rohc@ietf.org; Tue, 17 Jun 2003 14:40:15 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 19:42:24 +0100 Message-ID: From: "Price, Richard" To: "'Ghyslain Pelletier'" Cc: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed Date: Tue, 17 Jun 2003 19:42:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > The editor added formats for IR and IR-DYN in the ROHC-TCP draft because > he unfortunately hadn't realized that you also had a proposal for those > and was under the belief that the IRs would follow the same structure as > in RFC-3095. The idea was also to generate discussions on those to at > least move forward with IR formats, while waiting for the CO packets. I > should have added an author's note to this effect in the draft. Mea > culpa. Obviously the IRs will be adjusted based on agreements on the > list. > > On the other hand I do agree with Lars-Erik that the issue on how to > document the packet formats is the pressing issue. While this does not > prevent us to comment on the formats that you have suggested, it does > make it hard to include them to the ROHC-TCP draft at this point. I certainly agree that more discussion is required on how to present the packet formats in ROHC-TCP. However, doesn't the same apply for the IR and IR-DYN packets? We need to decide how to present them before we can include them in the ROHC-TCP draft. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jun 18 07:55:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28562 for ; Wed, 18 Jun 2003 07:55:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IBt4Z19053 for rohc-archive@odin.ietf.org; Wed, 18 Jun 2003 07:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbWq-0004xE-DK for rohc-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 07:55:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28553 for ; Wed, 18 Jun 2003 07:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SbUa-0002MT-00 for rohc-web-archive@ietf.org; Wed, 18 Jun 2003 07:52:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SbUa-0002MQ-00 for rohc-web-archive@ietf.org; Wed, 18 Jun 2003 07:52:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbWp-0004wr-9e; Wed, 18 Jun 2003 07:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbWB-0004ur-LA for rohc@optimus.ietf.org; Wed, 18 Jun 2003 07:54:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28443; Wed, 18 Jun 2003 07:54:22 -0400 (EDT) Message-Id: <200306181154.HAA28443@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Jun 2003 07:54:21 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-user-guide-00.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : SigComp User Guide Author(s) : R. Price et al. Filename : draft-ietf-rohc-sigcomp-user-guide-00.txt Pages : 38 Date : 2003-6-17 This document provides an informational guide for users of the SigComp protocol. The aim of the document is to assist users when making SigComp implementation decisions; for example the choice of compression algorithm and the level of robustness against lost or misordered packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-user-guide-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-ietf-rohc-sigcomp-user-guide-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-ietf-rohc-sigcomp-user-guide-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: <2003-6-17144736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-user-guide-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-user-guide-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144736.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jun 18 12:28:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15200 for ; Wed, 18 Jun 2003 12:28:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IGS2306676 for rohc-archive@odin.ietf.org; Wed, 18 Jun 2003 12:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SfBj-0008Bo-At for rohc-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 11:49:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13762 for ; Wed, 18 Jun 2003 11:49:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sf9T-00065G-00 for rohc-web-archive@ietf.org; Wed, 18 Jun 2003 11:47:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sf9S-00065C-00 for rohc-web-archive@ietf.org; Wed, 18 Jun 2003 11:47:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sem4-0006u5-P1; Wed, 18 Jun 2003 11:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Se23-00042p-QL for rohc@optimus.ietf.org; Wed, 18 Jun 2003 10:35:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10007 for ; Wed, 18 Jun 2003 10:35:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sdzm-0005D1-00 for rohc@ietf.org; Wed, 18 Jun 2003 10:33:06 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Sdzl-0005Cx-00 for rohc@ietf.org; Wed, 18 Jun 2003 10:33:05 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IEZMw2010294; Wed, 18 Jun 2003 16:35:22 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP88B5B; Wed, 18 Jun 2003 16:35:46 +0200 Received: by lms001.lu.erisoft.se id QAA00446; Wed, 18 Jun 2003 16:35:17 +0200 (MET DST) Message-ID: <3EF078D4.C71BB3D4@epl.ericsson.se> Date: Wed, 18 Jun 2003 16:36:05 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Lars-Erik Jonsson (EAB)" CC: Tommy Lundemo , rohc@ietf.org Subject: Re: [rohc] Mode transitions (was: (no subject)) References: 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-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Lars-Erik Jonsson (EAB)" wrote: > > Tommy, Ghyslain, and others, > > > > Would it be useful to introduce means for the compressor to > > > reject a mode change? > > > > That's an interesting question. I am also of the opinion that > > it would be useful to allow a compressor to decline a > > decompressor request for a mode transition. Right now the way > > RFC-3095 is written, mode changes are entirely a decompressor > > decision (why so?). > > I think this was just something we did not think of at that > point in time, we just agreed that the decompressor should be > the one initiating mode transitions, and we never even talked > about any other options than confirmations from the compressor. > However, as negotiations usually allow both sides to express > their opinion, I agree with you that it seems reasonable to > have such an alternative. > > The question is how to address this standardization-wise. We do > not want to upgrade the existing profiles just to add this, I > think, but let's keep it in our minds if we make new revision of > profiles 1-3. Maybe it would make sense to add it to the IP > profile, i.e. define the "reserved" value for the mode response > in that profile. I also think it is a good idea to add this in the IP profile. What is needed is to specify the bit and, as I mentionned earlier, add some minor logic with respect to the parameters C_MODE, C_TRANS, D_MODE and D_TRANS of rfc-3095 section 5.6.1 for the relevant transitions - to ensure that a decompressor request for a mode transition being declined by the compressor does complete with respect to these parameters. I think it should be possible to generalize the change in logic with respect to any transitions. > > > It seems like all the mode changes that requires the compressor to > > > send an IR/IR-DYN/UOR-2 packet could have used use the reserved bit > > > pattern for mode, to reject a mode change. > > > > This seems to be a potential approach. Some minor additional logic > > would also have to be introduced with respect to the parameters > > C_MODE, C_TRANS, D_MODE and D_TRANS of section 5.6.1 for the > > relevant transitions. > > Well, not very much, basically just state how a rejected mode > transition should be terminated. The compressor will still need to receive feedback with the unchanged mode to stop sending IR/IR-DYN/UOR-2 with the bit set to '0' (declining the mode transition) and to ensure that PT-0 and PT-1 formats will not be misinterpreted by the decompressor. This additional logic still seems to be also necessary, based on how mode transitions are currently performed in 3095. > > > > Is there any specific reason why the compressor is not allowed > > > to have an opinion in the mode changing procedure? > > Standardization that has progressed too quickly... > > BR > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jun 18 15:02:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22041 for ; Wed, 18 Jun 2003 15:02:17 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IJ1o601513 for rohc-archive@odin.ietf.org; Wed, 18 Jun 2003 15:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ShvO-00081B-Vs for rohc-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 14:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20654 for ; Wed, 18 Jun 2003 14:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sht7-00003D-00 for rohc-web-archive@ietf.org; Wed, 18 Jun 2003 14:42:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sht6-000039-00 for rohc-web-archive@ietf.org; Wed, 18 Jun 2003 14:42:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ShWP-0006mW-27; Wed, 18 Jun 2003 14:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sh71-0005Wq-67 for rohc@optimus.ietf.org; Wed, 18 Jun 2003 13:52:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18442 for ; Wed, 18 Jun 2003 13:52:45 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sh4k-0007KU-00 for rohc@ietf.org; Wed, 18 Jun 2003 13:50:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Sh4i-0007KL-00 for rohc@ietf.org; Wed, 18 Jun 2003 13:50:24 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5IHqd918704 for ; Wed, 18 Jun 2003 20:52:39 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Jun 2003 20:52:38 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 20:52:39 +0300 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 10:52:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Wed, 18 Jun 2003 12:52:13 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398866@daebe004.americas.nokia.com> Thread-Topic: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Thread-Index: AcM1AehHTBN0ni7QSO21zalvM8GP8AAp/oFQAAUUL9A= To: , , X-OriginalArrivalTime: 18 Jun 2003 17:52:14.0480 (UTC) FILETIME=[59E7D900:01C335C2] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA22041 Hi Gyslain, In summary, your comments are related to the modifications I proposed for the ROHC-CR feedback. I understand that you are not favoring the proposed modifications, but I do not understand the justification for it. The proposed modifications doesn't add any bits in the IR-REPLICATE packet, it only changes the 8-bit CRC coverage. It provides mechanism for detecting bad base context, only for the initial IR-REPLICATE packets and not after successful validation of the context (please see my 2nd last embedded comment below). If we don't incorporate the proposed modifications, in case of a bad context: 1) the compressor would continue to send N IR-REPLICATE packets and eventually send IR packet. There will be N-1 unnecessary transmission of IR-REPLICATE packets. 2) when a base context gets corrupted, it may continue to be used for the other context replications, and each of those would fail N IR-REPLICATE packets. There will be (num of bad base contexts)* (N-1) unnecessary transmission of IR-REPLICATE packets Thus, with proposed modifications we add robustness and compression efficiency. Could you tell me why you think the proposed modifications for feedback is unnecessary? Also, please find my specific comments below. Regards, Yousuf > Yousuf.Saifullah@nokia.com wrote: > > > > [Yousuf] I think it is possible to use STATIC-NACK for > > > indicating corruption in the base context, and another NACK > > > for indicating transmission error in IR-REPLICATE packet. We > > In my understanding, ACKs and NACKs are used to transmit information > regarding the state of the context (potentially at a specific > packet in > the SN space), not to provide information regarding the state of the > transmission. Therefore I do not really understand why there > would be a > need to define a new feedback option to indicate transmission error in > the IR-REPLICATE packet. > The need is to identify why the state of the context can't be changed? If the state of the context can't be changed because the base context is bad, the compressor could stop using the bad base context and start sending the IR packet. This helps in adding robustness and compression efficiency on the CR procedure, please also see my earlier comment. > > > have two CRCs. 7-bit CRC covers the original uncompressed > > > header and the 8-bit CRC covers the IR packet including > > > static and dynamic chain (this is with the change proposed in > > > my last email). If 8-bit CRC verifies integrity of IR- > > The extent of the coverage of the 8-bit CRC (other than the minimal > coverage required by RFC-3095) is profile dependent. It would be > unappropriate to define it as to include chains in this > draft, unless we > make context replication profile-specific. This is also in > line with one > of Richard's previous comment on this thread. > The mechanism I am suggesting for these two CRCs to provide, i.e. detection of error in the base context, is generic and applicable to all the profiles. Even though, 8-bit CRC is defined as a profile dependent parameter, this mechanism is general and is appropriate to capture it in the CR draft. Moreover, the CR draft does mention coverage of CRC, the following is a quote from 8-bit CRC section: "MUST cover at least the initial part of the packet ending with the Profile field and if present, the Base CID field" This would be changed to: "MUST cover the IR packet excluding payload" If we can put the former text in the draft, then we can also put the later text in the draft. There are also other examples in the CR draft where those profile-specific information which are generic to multiple profiles are mentioned, e.g. use of a different CID than the Base CID, and mentioning of 7-bit CRC under Profile Specific Information. I am not asking to take this out. I think it is good to put these text, so the CR draft would serve as a better base document for the profile dependent documents. > > > REPLICATE packet header, but the 7-bit CRC failed after > > > decompression, then this implies that we have a problem in > > > the base context. In this case only the decompressor will > > > send a STATIC-NACK indicating that the decompression failed > > > due to the problem in the base context. The compressor would > > > discard that base context and send IR packet. > > Only for the "one or more initial IR-REPLICATE packets", as currently > stated in the draft. > > "Price, Richard" wrote: > > > Page 6: "Upon reception of a NACK, the compressor may assume > > that the static part of the decompressor context is valid but > > that the dynamic part is invalid, and take actions accordingly." > > > > Again, could this also be used by the compressor as evidence > > that something is wrong with the base context? > > Not in this case. See previous comment. > > Yousuf.Saifullah@nokia.com wrote: > > > > [Yousuf] Can we solve this concern by adding IR-REPLICATE > > > state between IR and CO state in the compressor state machine > > > as shown below. > > > > > > Optimistic approach / ACK ACK > > > +------>-------->------>------>---------+ +->-+ > > > | Base Ctxt Avail ACK | | | > > > | +----------+ +---->---->---------|| | | > > > | | V | vv | v > > > +----------+ +--------------+ +----------+ > > > | IR State | | IR-REP State | | CO State | > > > +----------+ +--------------+ +----------+ > > > ^ ^ | ^ | | > > > | +---<-----+ +-<-+ | > > > | STATIC-NACK Timeout/NACK | > > > | | > > > | Timeout / NACK / STATIC-NACK | > > > +-------<-------<-------<-------<--------+ > > > > > > I think this is also what context context replication is > > > doing. > > Replication is a complement to the context initialization. I do not > really see the relevance of adding a new state for context > replication. > This is in response to the Richard's comment you quoted below. His concern regarding not sending STATIC-NACK in IR state for R-mode is solved by the above diagram. Please also see my next comment. > "Price, Richard" wrote: > > > Page 7: "Specifically, when the decompressor fails to validate > > the context following the decompression of one or more initial > > IR-REPLICATE packets, it MUST invalidate the context and remain > > in its initial state. In addition, the decompressor SHOULD send > > a STATIC-NACK." > > > > This logic is fine for O-mode and B-mode, but I think that > > different logic is required in the case of R-mode. From RFC 3095: > > > > "The decompressor SHOULD NOT send STATIC-NACK(R) when > > receiving an IR packet that fails the CRC check, as the > > compressor will stay in IR state and thus continue sending > > IR packets until a valid ACK is received" > > > > The above also applies to an IR-REPLICATE packet, so the > > decompressor SHOULD NOT send a STATIC-NACK in this case. > > In my understanding, if the CRC fails for the IR we cannot deduce > anything as to the validity of the context, as the 8-bit CRC is > calculated over information contained in the packet only. Thus in my > understanding the text in the draft still means that in this case the > decompressor would not send STATIC-NACK anyway, so in my understanding > this would not conflict with respect to R-mode. Furthermore, modes are > actually profile dependent, not generic to all profiles, so this draft > should not go in more details regarding this in my opinion. > The decompressor can deduce the validity of the context using two CRCs in the IR-REPLICATE packet. If the context is bad, it can send STATIC-NACK right away as mentioned earlier. This is different from the text in the draft but improves the overall procedure. Regarding documenting R-mode specific text in CR draft. If something is anticipated to be generic for R-modes and also for multiple profiles, then instead of repeating the common text in the multiple profile specific drafts it would be better to document the common text in the CR draft. The text from the draft implies U and B mode, that's where the confusion has arised. If we try to abstract the text too much we would loose information and cause confusion, therefore it is better to expand and put the R-mode also. > Yousuf.Saifullah@nokia.com wrote: > > > - I think we can improve on failure mechanism mentioned in the > > above two sections. The draft mentions that if the > > decompression of IR-REPLICATE fails, the decompressor will send > > STATIC NACK and the compressor MUST refrain from IR-REPLICATE, > > in other words use IR packets. Moving to IR means sending more > > > > bytes compared to IR-REPLICATE, hence degrading compression > > efficiency. If the decompression has failed due to transmission > > error of IR-REPLICATE (case-1), then the decompressor is > > unnecessarily asking for IR. It is better to ask for the > > retransmission of IR-REPLICATE and gain more compression > > efficiency. Not to mention, retransmitting an already encoded > > packet would be faster for the compressor. It is also possible > > that the decompression has failed because of the corruption in > > the base context (case-2). In case-2 we definitely want to move > > to the IR packet, since there is no way to fix it without > > sending full header. > > Case-1 would normally not trigger feedback. Case-2 would normally > trigger a NACK. An additional case is when N IR-REPLICATE received > (where k out of N succeed 8-bit CRC validation) would not succeed into > replicating a context (7-bit CRC fails for k); this would trigger > STATIC-NACK. > Your comment is only based on the CR daft. My above comment has suggested an improvement and that improvement sends feedback in case-1. Could you please comment on the proposed improvement. > > I'd propose that the decompressor should differentiate between > > the two cases. It can be done if we increase the coverage of 8- > > bit CRC (section 3.4.1.2)to cover static and dynamic chain > > also. The CRC of an IR or IR-DYN covers the whole IR packet, > > excluding payload (section 5.9.2 of RFC 3095). The proposed > > change in 8-bit CRC is more in line with the IR and IR-DYN CRC. > > This would correspond to a requirement on something that is actually > profile specific. The draft only put requirements on the > minimal extent > of the coverage for the 8-bit CRC. Please see my an earlier comment on profile specifics. > > > The logic would work something like this: > > - if 7-bit CRC failed, send STATIC-NACK > > This would prevent the IR-REPLICATE to be used like any other > compressed > packet. A failure to decompress one such packet does not necessarily > means that the static part in invalid. > I think I see your concern, we need to handle two cases as mentioned in section 3.3.2 of the CR draft: Case-1: 2nd para -Upon failures of one ore more initial IR-REPLICATE, the CR draft also sends STATIC-NACK which in turn triggers IR. It doesn't provides a mechanism for validating and using the static part, so the proposed modification doesn't have any issue with this. Case -2: 3rd para - After successful validation of the replicated context, there is no need for sending STATIC-NACK, and a NACK as suggested in the CR draft can be used. In this way static part can be used, if desired. This has no issue with the proposed modification, as the base context has been successfully validated and the proposed modification won't be sending STATIC-NACK. > > - if 8-bit CRC fails, send another NACK (let's call it REP- > > NACK). > > The 8-bit CRC protects the integrity of the IR packet itself. while > feedback is used to convey information regarding the state of the > context. In my opinion, it would be not be proper to define a new > feedback type to report a transmission error instead of > considering the > state of the context. > I think that is an incorrect description of the purpose of the new feedback type. The feedback is not reporting a transmission error. It is reporting why the state of the context can't be changed. The information is used for increasing robustness and improving compression efficiency, as mentioned earlier in this email. > > We could differentiate a REP-NACK from a regular NACK by using > > feedback options in the FEEDBACK-2 format and make this option > > available to other profiles besides TCP. We could have used > > In my opinion, this is not necessary. Also, I would be reluctant to > define a new feedback option if I can avoid it. > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jun 19 07:34:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09668 for ; Thu, 19 Jun 2003 07:34:23 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JBXso07040 for rohc-archive@odin.ietf.org; Thu, 19 Jun 2003 07:33:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxY5-0001Z5-NK for rohc-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 07:25:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08913 for ; Thu, 19 Jun 2003 07:25:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SxVo-0001nr-00 for rohc-web-archive@ietf.org; Thu, 19 Jun 2003 07:23:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SxVn-0001no-00 for rohc-web-archive@ietf.org; Thu, 19 Jun 2003 07:23:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxJl-0000ut-LL; Thu, 19 Jun 2003 07:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxFA-0000Rm-49 for rohc@optimus.ietf.org; Thu, 19 Jun 2003 07:06:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08522 for ; Thu, 19 Jun 2003 07:06:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SxCr-0001hp-00 for rohc@ietf.org; Thu, 19 Jun 2003 07:03:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SxCq-0001hm-00 for rohc@ietf.org; Thu, 19 Jun 2003 07:03:52 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5JB6BG5025155; Thu, 19 Jun 2003 13:06:11 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQRAML; Thu, 19 Jun 2003 13:07:26 +0200 Received: by lms001.lu.erisoft.se id NAA18605; Thu, 19 Jun 2003 13:04:26 +0200 (MET DST) Message-ID: <3EF198E4.6CFA9237@epl.ericsson.se> Date: Thu, 19 Jun 2003 13:05:08 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yousuf.Saifullah@nokia.com CC: richard.price@roke.co.uk, rohc@ietf.org Subject: Re: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) References: <025E7DD4182874489CC2F61EE0FA19CE01398866@daebe004.americas.nokia.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id NAA18605 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA09668 Yousouf, I appreciate your comments. Those suggestions that I do not favor are because I do not see (or understand) their motivations. Obviously in such case it would be useful if someone else on the list joins in to help us out. See further comments inline. /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com Yousuf.Saifullah@nokia.com wrote: > > Hi Ghyslain, > > In summary, your comments are related to the modifications I > proposed for the ROHC-CR feedback. I understand that you are not > favoring the proposed modifications, but I do not understand the > justification for it. > > The proposed modifications doesn't add any bits in the IR-REPLICATE > packet, it only changes the 8-bit CRC coverage. The draft is currently written to be generic and reused by any profiles. Because the IR-REPLICATE is a ROHC IR packet, the minimal coverage of this CRC must follow RFC-3095. RFC-3095 also states that this coverage may be extended to cover more (such as including any information that initializes the context), but that this should be defined on a per-profile basis. I cannot think of any specific reason why this was specified like this, however I have chosen to do the same when writing ROHC-CR. So, trying to clarify your comments and if I understand correctly, your question regarding the CRC-8 is thus: Q1) should we mandate that every profile supporting ROHC-CR calculates the CRC-8 over the entire IR-REPLICATE packet, excluding the payload? Regarding this, I still favor that each profile specify this itself. However, I have no strong feelings about this, as ultimately I suspect that any profile would do just that. The coverage of the 8-bit CRC in the IR-REPLICATE > It provides > mechanism for detecting bad base context, only for the initial > IR-REPLICATE packets and not after successful validation of the > context (please see my 2nd last embedded comment below). This is were I fail to follow you. In my understanding, the 8-bit CRC - calculated over information contained in the IR packet - is not what provides the "mechanism for detecting a bad base context". This CRC will only allow you to detect that there has been an error in the received packet (transmission error), and since the information covered by this CRC includes CID it is difficult to take proper action more than to discard the packet. > If we don't > incorporate the proposed modifications, in case of a bad context: > > 1) the compressor would continue to send N IR-REPLICATE packets and > eventually send IR packet. There will be N-1 unnecessary > transmission of IR-REPLICATE packets. > When the CRC-8 of the IR-REPLICATE fails to verify, the decompressor does not take any different actions than those stated in RFC-3095, section 5.2.6 (see item #10). Maybe this needs to be clarified? I could add a section "initial decompressor processing", that would add a paragraph identical to item #10? The CRC that is used for detecting a faulty context is the 7-bit CRC for which ROHC-CR states that its presence is mandatory within the "profile specific information" of the IR-REPLICATE packet. The CRC-7 is calculated over the original, uncompressed header and thus verifies decompressor (validity of the context). In summary, the CRC-8 is present to make sure that an IR-REPLICATE initializing a new context using replication has had its CID and profile validated, and that the information that initializes the context was received without error. Since with replication some of this information is sent compressed already within the first IR-REPLICATE, the CRC-7 is necessary to verify the decompression - thus in turn to verifying that replication was successful (i.e. the base context used was ok!). See ROHC-CR section 3.1. Now, when the CRC-7 in the IR-REPLICATE fails to verify the decompressed header, this is when the decompressor might generate feedback. Section 3.3.2 states that: 1) ACK should be sent when one or more IR-REPLICATE succeeds CRC-7 validation, i.e. decompression succeeded -> context is ok. 2) NACK should be sent when one or more IR-REPLICATE fails CRC-7 validation in the following case: o a context had been successfully established prior to the packet(s) for which decompression failed I.e. case A: A valid context had been successfully established for that flow, but decompression failed for one or more packets -> context went from ok to not ok and is now a "bad context". 3) STATIC-NACK should be sent when one or more IR-REPLICATE fails CRC-7 validation in the following case: o no context has yet been established for this flow prior to the packet(s) for which decompression failed. I.e. case B: No valid context has been established for that flow, and decompression fails for one or more packets -> context never established and is not suited to be a base context (is a "bad context" for replication). Thus, case A is not triggering the sending of IRs, case B does. > 2) when a base context gets corrupted, it may continue to be used > for the other context replications, and each of those would fail N > IR-REPLICATE packets. There will be (num of bad base contexts)* > (N-1) unnecessary transmission of IR-REPLICATE packets Here I fail to understand how this could be. A base context that gets corrupted will not be used for replicating other context, as it would have been NACKed and thus fails the requirements for the selection of a base context (i.e. must have been ACKed and valid at the compressor at the time of replication). > Thus, with proposed modifications we add robustness and compression > efficiency. Could you tell me why you think the proposed > modifications for feedback is unnecessary? > > Also, please find my specific comments below. > > Regards, > Yousuf > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > [Yousuf] I think it is possible to use STATIC-NACK for > > > > indicating corruption in the base context, and another NACK > > > > for indicating transmission error in IR-REPLICATE packet. We > > > > In my understanding, ACKs and NACKs are used to transmit information > > regarding the state of the context (potentially at a specific > > packet in > > the SN space), not to provide information regarding the state of the > > transmission. Therefore I do not really understand why there > > would be a > > need to define a new feedback option to indicate transmission error in > > the IR-REPLICATE packet. > > > The need is to identify why the state of the context can't be > changed? If the state of the context can't be changed because the > base context is bad, the compressor could stop using the bad base > context and start sending the IR packet. This helps in adding > robustness and compression efficiency on the CR procedure, please > also see my earlier comment. What do you mean "why the state of the context can't be changed"? Do you mean that it failed to validate the decompression (CRC-7) and thus the packet can't update the context? Your original request is to add "another NACK for indicating transmission error in IR-REPLICATE packet". This is what I fail to see a justification for. As I previously explained, my understanding is that feedback with ROHC is meant to carry information regarding the state of the decompressor context back to the compressor, not to carry information about transmission errors. Identifying why a context becomes invalid and which of STATIC-NACK or NACK should be sent is explained above. Recall that both FEEDBACK-1 and FEEDBACK-2 carries SN bits that corresponds to the sequence number of the header (e.g. IR-REPLICATE) that caused the feedback information to be sent. If no sequence number can be determined, then the feedback carries the SN-NOT-VALID option. This is useful for the compressor to determine the cause of the problem. > > > > have two CRCs. 7-bit CRC covers the original uncompressed > > > > header and the 8-bit CRC covers the IR packet including > > > > static and dynamic chain (this is with the change proposed in > > > > my last email). If 8-bit CRC verifies integrity of IR- > > > > The extent of the coverage of the 8-bit CRC (other than the minimal > > coverage required by RFC-3095) is profile dependent. It would be > > unappropriate to define it as to include chains in this > > draft, unless we > > make context replication profile-specific. This is also in > > line with one > > of Richard's previous comment on this thread. > > > The mechanism I am suggesting for these two CRCs to provide, i.e. > detection of error in the base context, is generic and applicable to > all the profiles. Even though, 8-bit CRC is defined as a profile > dependent parameter, this mechanism is general and is appropriate to > capture it in the CR draft. Moreover, the CR draft does mention > coverage of CRC, the following is a quote from 8-bit CRC section: Up to here, I do not understand what it is that you are proposing regarding the CRCs that is not already addressed in the ROHC-CR draft. > "MUST cover at least the initial part of the packet ending with the > Profile field and if present, the Base CID field" > This would be changed to: > "MUST cover the IR packet excluding payload" See Q1) above. This is exactly the same question. > If we can put the former text in the draft, then we can also put the > later text in the draft. > > There are also other examples in the CR draft where those > profile-specific information which are generic to multiple profiles > are mentioned, e.g. use of a different CID than the Base CID, and > mentioning of 7-bit CRC under Profile Specific Information. I am not > asking to take this out. I think it is good to put these text, so the > CR draft would serve as a better base document for the profile > dependent documents. I don't think there is a contradiction here either. > > > > REPLICATE packet header, but the 7-bit CRC failed after > > > > decompression, then this implies that we have a problem in > > > > the base context. In this case only the decompressor will > > > > send a STATIC-NACK indicating that the decompression failed > > > > due to the problem in the base context. The compressor would > > > > discard that base context and send IR packet. > > > > Only for the "one or more initial IR-REPLICATE packets", as currently > > stated in the draft. > > > > "Price, Richard" wrote: > > > > > Page 6: "Upon reception of a NACK, the compressor may assume > > > that the static part of the decompressor context is valid but > > > that the dynamic part is invalid, and take actions accordingly." > > > > > > Again, could this also be used by the compressor as evidence > > > that something is wrong with the base context? > > > > Not in this case. See previous comment. > > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > [Yousuf] Can we solve this concern by adding IR-REPLICATE > > > > state between IR and CO state in the compressor state machine > > > > as shown below. > > > > > > > > Optimistic approach / ACK ACK > > > > +------>-------->------>------>---------+ +->-+ > > > > | Base Ctxt Avail ACK | | | > > > > | +----------+ +---->---->---------|| | | > > > > | | V | vv | v > > > > +----------+ +--------------+ +----------+ > > > > | IR State | | IR-REP State | | CO State | > > > > +----------+ +--------------+ +----------+ > > > > ^ ^ | ^ | | > > > > | +---<-----+ +-<-+ | > > > > | STATIC-NACK Timeout/NACK | > > > > | | > > > > | Timeout / NACK / STATIC-NACK | > > > > +-------<-------<-------<-------<--------+ > > > > > > > > I think this is also what context context replication is > > > > doing. > > > > Replication is a complement to the context initialization. I do not > > really see the relevance of adding a new state for context > > replication. > > Your original question was: Q2) Should we add an additional state called IR-REP? I fail to understand how in general this new state would be motivated. I don't see that this is needed. For me, the IR-REPLICATE corresponds to the IR state just like the IR does. Furthermore, states a profile specific and the ROHC-CR is not. Your drawing seems to have the state machine of ROHC-TCP in mind. > This is in response to the Richard's comment you quoted below. His > concern regarding not sending STATIC-NACK in IR state for R-mode is > solved by the above diagram. Please also see my next comment. This is a different issue and I fail to see its relation with adding yet another state. The question is: Q3) Can the mode be replicated? First, note that modes are profile specific. My opinion is that if the ROHC-CR draft is to stay generic, than there shouldn't be anything specific to R-mode in it. Second, my opinion is that the mode can't be replicated. It is nothing that is necessary to replicate. Inaddition, this also would cause problems with inter-profile replication. A replicated context should start in its initial mode after replication, and the initial feedback to the IR-REPLICATE may be used to make a mode change (FEEDBACK-2 only in this case when ACKing) , if applicable. Wouldn't this be the simplest thing to do? I think replicating the mode does not make sense. > > "Price, Richard" wrote: > > > > > Page 7: "Specifically, when the decompressor fails to validate > > > the context following the decompression of one or more initial > > > IR-REPLICATE packets, it MUST invalidate the context and remain > > > in its initial state. In addition, the decompressor SHOULD send > > > a STATIC-NACK." > > > > > > This logic is fine for O-mode and B-mode, but I think that > > > different logic is required in the case of R-mode. From RFC 3095: > > > > > > "The decompressor SHOULD NOT send STATIC-NACK(R) when > > > receiving an IR packet that fails the CRC check, as the > > > compressor will stay in IR state and thus continue sending > > > IR packets until a valid ACK is received" > > > > > > The above also applies to an IR-REPLICATE packet, so the > > > decompressor SHOULD NOT send a STATIC-NACK in this case. > > > > In my understanding, if the CRC fails for the IR we cannot deduce > > anything as to the validity of the context, as the 8-bit CRC is > > calculated over information contained in the packet only. Thus in my > > understanding the text in the draft still means that in this case the > > decompressor would not send STATIC-NACK anyway, so in my understanding > > this would not conflict with respect to R-mode. Furthermore, modes are > > actually profile dependent, not generic to all profiles, so this draft > > should not go in more details regarding this in my opinion. > > > The decompressor can deduce the validity of the context using two > CRCs in the IR-REPLICATE packet. If the context is bad, it can send > STATIC-NACK right away as mentioned earlier. This is different from > the text in the draft but improves the overall procedure. I don't see that the consequence of the text in the draft is any different from this result, and thus I can't see the improvement from the text in the draft either. Refer to the above explanation of the text in the draft. If you still feel that there is improvement, please be more specific in your comment. > Regarding documenting R-mode specific text in CR draft. If something > is anticipated to be generic for R-modes and also for multiple > profiles, then instead of repeating the common text in the multiple > profile specific drafts it would be better to document the common > text in the CR draft. The text from the draft implies U and B mode, > that's where the confusion has arised. If we try to abstract the text > too much we would loose information and cause confusion, therefore it > is better to expand and put the R-mode also. I strongly disagree. R-mode is not a part of the generic ROHC framework, it is rather specific to certain profiles only. This is not something that all ROHC profiles needs to have or support. Note that R-mode also has its own set of packet format and modes are useful to ensure that packet type identifiers common to U/O-mode and R-mode will not be misinterpreted, in addition to having a different feedback logic. However for ROHC-TCP in particular, and possibly future compression profiles, we should hopefully limit ourselves to one set of packet formats for the lifetime of a context. This is the path taken with ROHC-TCP, and I believe this is also in-line with the use of the formal notation as a tool to help us generate packet formats. Thus, and I hope others will agree with me, let's not discuss R-mode and context replication further at this point we should not write any text specific to R-mode in the ROHC-CR draft. I believe that the more generic approach is to focus on a U and B mode type of operation. > > > Yousuf.Saifullah@nokia.com wrote: > > > > > - I think we can improve on failure mechanism mentioned in the > > > above two sections. The draft mentions that if the > > > decompression of IR-REPLICATE fails, the decompressor will send > > > STATIC NACK and the compressor MUST refrain from IR-REPLICATE, > > > in other words use IR packets. Moving to IR means sending more > > > > > > > bytes compared to IR-REPLICATE, hence degrading compression > > > efficiency. If the decompression has failed due to transmission > > > error of IR-REPLICATE (case-1), then the decompressor is > > > unnecessarily asking for IR. It is better to ask for the > > > retransmission of IR-REPLICATE and gain more compression > > > efficiency. Not to mention, retransmitting an already encoded > > > packet would be faster for the compressor. It is also possible > > > that the decompression has failed because of the corruption in > > > the base context (case-2). In case-2 we definitely want to move > > > to the IR packet, since there is no way to fix it without > > > sending full header. > > > > Case-1 would normally not trigger feedback. Case-2 would normally > > trigger a NACK. An additional case is when N IR-REPLICATE received > > (where k out of N succeed 8-bit CRC validation) would not succeed into > > replicating a context (7-bit CRC fails for k); this would trigger > > STATIC-NACK. > > > Your comment is only based on the CR daft. My above comment has > suggested an improvement and that improvement sends feedback in > case-1. Could you please comment on the proposed improvement. My comments address the ROHC-CR draft only. Also see explanations above regarding feedack. > > > I'd propose that the decompressor should differentiate between > > > the two cases. It can be done if we increase the coverage of 8- > > > bit CRC (section 3.4.1.2)to cover static and dynamic chain > > > also. The CRC of an IR or IR-DYN covers the whole IR packet, > > > excluding payload (section 5.9.2 of RFC 3095). The proposed > > > change in 8-bit CRC is more in line with the IR and IR-DYN CRC. > > > > This would correspond to a requirement on something that is actually > > profile specific. The draft only put requirements on the > > minimal extent > > of the coverage for the 8-bit CRC. > > Please see my an earlier comment on profile specifics. Your proposed change is in-line with the profile-specific part of the CRC in IR and IR-DYN. The text in the ROHC-CR draft is aligned with the profile independant part of the CRC in IR and IR-DYN (see RFC-3095 section 5.2.3.). See Q1) above. > > > > > The logic would work something like this: > > > - if 7-bit CRC failed, send STATIC-NACK > > > > This would prevent the IR-REPLICATE to be used like any other > > compressed > > packet. A failure to decompress one such packet does not necessarily > > means that the static part in invalid. > > > I think I see your concern, we need to handle two cases as mentioned in section 3.3.2 of the CR draft: > > Case-1: 2nd para -Upon failures of one ore more initial IR-REPLICATE, > the CR draft also sends STATIC-NACK which in turn triggers IR. It > doesn't provides a mechanism for validating and using the static > part, so the proposed modification doesn't have any issue with this. This case is only about the decompressor sending STATIC-NACK when it could not establish a context following a number (one or more) of _initial_ IR-REPLICATE packets - because of a faulty base context (i.e. the static part is not known to be usable). Thus as a result it is accurate for the compressor to start sending IRs instead. > Case -2: 3rd para - After successful validation of the replicated > context, there is no need for sending STATIC-NACK, and a NACK as > suggested in the CR draft can be used. In this way static part can be > used, if desired. This has no issue with the proposed modification, > as the base context has been successfully validated and the proposed > modification won't be sending STATIC-NACK. In this case the draft states is also correct, right? > > > - if 8-bit CRC fails, send another NACK (let's call it REP- > > > NACK). > > > > The 8-bit CRC protects the integrity of the IR packet itself. while > > feedback is used to convey information regarding the state of the > > context. In my opinion, it would be not be proper to define a new > > feedback type to report a transmission error instead of > > considering the > > state of the context. > > > > I think that is an incorrect description of the purpose of the new > feedback type. The feedback is not reporting a transmission error. It > is reporting why the state of the context can't be changed. The > information is used for increasing robustness and improving > compression efficiency, as mentioned earlier in this email. If I rephrase your comment, you mean that the new feedback type would convey information regarding why the context could not be updated, correct? A context is updated when decompression succeeds (i.e. when the CRC validates the decompressed header - in this case when the CRC-7 of the IR-REPLICATE succeeds). When the CRC-8 of the IR-REPLICATE fails, it does not provide the decompressor with any other information that there has been a transmission error. Specifically, decompression is not even attempted, and the error might even be on the CID field, base CID field or profile field of the IR-REPLICATE - thus in this case what this option would transmit cannot relate to the state of the context (neither to the state of the base context). And I don't believe that a new feedback option that carries information that does not relate to the state of the context is justified. If I misunderstand your comment, please clarify it. Thanks! > > > We could differentiate a REP-NACK from a regular NACK by using > > > feedback options in the FEEDBACK-2 format and make this option > > > available to other profiles besides TCP. We could have used > > > > In my opinion, this is not necessary. Also, I would be reluctant to > > define a new feedback option if I can avoid it. > > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jun 19 14:16:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07039 for ; Thu, 19 Jun 2003 14:16:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JIG3N14628 for rohc-archive@odin.ietf.org; Thu, 19 Jun 2003 14:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3x4-0003nr-Ub for rohc-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 14:16:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07001 for ; Thu, 19 Jun 2003 14:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3ul-0000sA-00 for rohc-web-archive@ietf.org; Thu, 19 Jun 2003 14:13:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3uk-0000s6-00 for rohc-web-archive@ietf.org; Thu, 19 Jun 2003 14:13:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3x3-0003nc-Dy; Thu, 19 Jun 2003 14:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3w9-0003VG-DL for rohc@optimus.ietf.org; Thu, 19 Jun 2003 14:15:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06734 for ; Thu, 19 Jun 2003 14:15:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3tp-0000nh-00 for rohc@ietf.org; Thu, 19 Jun 2003 14:12:41 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19T3tX-0000lk-00 for rohc@ietf.org; Thu, 19 Jun 2003 14:12:24 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jun 2003 19:14:08 +0100 Message-ID: From: "Price, Richard" To: "'Ghyslain Pelletier'" , Yousuf.Saifullah@nokia.com Cc: rohc@ietf.org Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Thu, 19 Jun 2003 19:14:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA07039 > I appreciate your comments. Those suggestions that I do not favor are > because I do not see (or understand) their motivations. Obviously in > such case it would be useful if someone else on the list joins in to > help us out. I guess this means me ;-) > See further comments inline. > > /Ghyslain > > Ghyslain Pelletier, Dipl. Ing. > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit > > Ericsson AB, Laboratoriegränd 11 > Box 920, S-97128 Luleå, SWEDEN > Phone : +46 (0) 920 20 24 32 > Mobile: +46 (0) 706 09 27 73 > Ghyslain.Pelletier@epl.ericsson.se > http://www.ericsson.com > > Yousuf.Saifullah@nokia.com wrote: > > > > Hi Ghyslain, > > > > In summary, your comments are related to the modifications I > > proposed for the ROHC-CR feedback. I understand that you are not > > favoring the proposed modifications, but I do not understand the > > justification for it. > > > > The proposed modifications doesn't add any bits in the IR-REPLICATE > > packet, it only changes the 8-bit CRC coverage. > > The draft is currently written to be generic and reused by any profiles. > Because the IR-REPLICATE is a ROHC IR packet, the minimal coverage of > this CRC must follow RFC-3095. RFC-3095 also states that this coverage > may be extended to cover more (such as including any information that > initializes the context), but that this should be defined on a > per-profile basis. I cannot think of any specific reason why this was > specified like this, however I have chosen to do the same when writing > ROHC-CR. So, trying to clarify your comments and if I understand > correctly, your question regarding the CRC-8 is thus: > > Q1) should we mandate that every profile supporting ROHC-CR calculates > the CRC-8 over the entire IR-REPLICATE packet, excluding the > payload? > > Regarding this, I still favor that each profile specify this itself. > However, I have no strong feelings about this, as ultimately I suspect > that any profile would do just that. I don't see any reason *not* to specify the CRC-8 coverage in the context replication draft, as we're already specifying features that are far more profile-specific than this (which is by no means a bad thing!). > The coverage of the 8-bit CRC in the IR-REPLICATE > > > It provides > > mechanism for detecting bad base context, only for the initial > > IR-REPLICATE packets and not after successful validation of the > > context (please see my 2nd last embedded comment below). > > This is were I fail to follow you. In my understanding, the 8-bit CRC - > calculated over information contained in the IR packet - is not what > provides the "mechanism for detecting a bad base context". This CRC will > only allow you to detect that there has been an error in the received > packet (transmission error), and since the information covered by this > CRC includes CID it is difficult to take proper action more than to > discard the packet. Another possible action upon receiving an IR packet which fails the 8-bit CRC is to send a STATIC-NACK (e.g. O-mode from RFC 3095 does this). It's not 100% guaranteed that the STATIC-NACK will refer to the correct CID, but this is no different from the case where a CRC over the decompressed header fails. > > If we don't > > incorporate the proposed modifications, in case of a bad context: > > > > 1) the compressor would continue to send N IR-REPLICATE packets and > > eventually send IR packet. There will be N-1 unnecessary > > transmission of IR-REPLICATE packets. It's not the case that a bad base context will cause N-1 unnecessary transmissions of an IR-REPLICATE packet. Instead the CRC-7 will fail, causing the decompressor to send a STATIC-NACK and the compressor to transit back to sending vanilla IR packets. > When the CRC-8 of the IR-REPLICATE fails to verify, the decompressor > does not take any different actions than those stated in RFC-3095, > section 5.2.6 (see item #10). Maybe this needs to be clarified? I could > add a section "initial decompressor processing", that would add a > paragraph identical to item #10? > > The CRC that is used for detecting a faulty context is the 7-bit CRC for > which ROHC-CR states that its presence is mandatory within the "profile > specific information" of the IR-REPLICATE packet. The CRC-7 is > calculated over the original, uncompressed header and thus verifies > decompressor (validity of the context). > > In summary, the CRC-8 is present to make sure that an IR-REPLICATE > initializing a new context using replication has had its CID and profile > validated, and that the information that initializes the context was > received without error. Since with replication some of this information > is sent compressed already within the first IR-REPLICATE, the CRC-7 is > necessary to verify the decompression - thus in turn to verifying that > replication was successful (i.e. the base context used was ok!). See > ROHC-CR section 3.1. > > Now, when the CRC-7 in the IR-REPLICATE fails to verify the decompressed > header, this is when the decompressor might generate feedback. Section > 3.3.2 states that: > > 1) ACK should be sent when one or more IR-REPLICATE succeeds CRC-7 > validation, i.e. decompression succeeded -> context is ok. > > 2) NACK should be sent when one or more IR-REPLICATE fails CRC-7 > validation in the following case: > o a context had been successfully established prior to the packet(s) > for which decompression failed > I.e. case A: > A valid context had been successfully established for that > flow, but decompression failed for one or more packets -> context > went from ok to not ok and is now a "bad context". > > 3) STATIC-NACK should be sent when one or more IR-REPLICATE fails > CRC-7 validation in the following case: > o no context has yet been established for this flow prior to the > packet(s) for which decompression failed. > I.e. case B: > No valid context has been established for that flow, and > decompression fails for one or more packets -> context never > established and is not suited to be a base context > (is a "bad context" for replication). > > Thus, case A is not triggering the sending of IRs, case B does. > > > 2) when a base context gets corrupted, it may continue to be used > > for the other context replications, and each of those would fail N > > IR-REPLICATE packets. There will be (num of bad base contexts)* > > (N-1) unnecessary transmission of IR-REPLICATE packets > > Here I fail to understand how this could be. A base context that gets > corrupted will not be used for replicating other context, as it would > have been NACKed and thus fails the requirements for the selection of a > base context (i.e. must have been ACKed and valid at the compressor at > the time of replication). There are definitely some cases where the base context can get corrupted and still be used for replicating other contexts (for example, it might become corrupted after being ACKed). However, I think that the existing NACK and STATIC-NACK mechanisms are sufficient to detect these cases (in particular, the CRC-7 would catch the faulty base context and cause a NACK or STATIC-NACK to be sent). > > Thus, with proposed modifications we add robustness and compression > > efficiency. Could you tell me why you think the proposed > > modifications for feedback is unnecessary? > > > > Also, please find my specific comments below. > > > > Regards, > > Yousuf > > > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > > > [Yousuf] I think it is possible to use STATIC-NACK for > > > > > indicating corruption in the base context, and another NACK > > > > > for indicating transmission error in IR-REPLICATE packet. We > > > > > > In my understanding, ACKs and NACKs are used to transmit information > > > regarding the state of the context (potentially at a specific packet in > > > the SN space), not to provide information regarding the state of the > > > transmission. Therefore I do not really understand why there would be a > > > need to define a new feedback option to indicate transmission error in > > > the IR-REPLICATE packet. > > > > > The need is to identify why the state of the context can't be > > changed? If the state of the context can't be changed because the > > base context is bad, the compressor could stop using the bad base > > context and start sending the IR packet. This helps in adding > > robustness and compression efficiency on the CR procedure, please > > also see my earlier comment. I think that the compressor can stop using a bad base context and switch to IR packets, using the NACK and STATIC-NACK mechanisms that are already available. If the compressor receives a NACK or STATIC-NACK then it knows that something is wrong with the context, so it must be refreshed using an IR(-DYN) packet. > What do you mean "why the state of the context can't be changed"? Do you > mean that it failed to validate the decompression (CRC-7) and thus the > packet can't update the context? > > Your original request is to add "another NACK for indicating > transmission error in IR-REPLICATE packet". This is what I fail to see a > justification for. As I previously explained, my understanding is that > feedback with ROHC is meant to carry information regarding the state of > the decompressor context back to the compressor, not to carry > information about transmission errors. Identifying why a context becomes > invalid and which of STATIC-NACK or NACK should be sent is explained > above. Recall that both FEEDBACK-1 and FEEDBACK-2 carries SN bits that > corresponds to the sequence number of the header (e.g. IR-REPLICATE) > that caused the feedback information to be sent. If no sequence number > can be determined, then the feedback carries the SN-NOT-VALID option. > This is useful for the compressor to determine the cause of the problem. > > > > > > have two CRCs. 7-bit CRC covers the original uncompressed > > > > > header and the 8-bit CRC covers the IR packet including > > > > > static and dynamic chain (this is with the change proposed in > > > > > my last email). If 8-bit CRC verifies integrity of IR- > > > > > > The extent of the coverage of the 8-bit CRC (other than the minimal > > > coverage required by RFC-3095) is profile dependent. It would be > > > unappropriate to define it as to include chains in this draft, unless we > > > make context replication profile-specific. This is also in line with one > > > of Richard's previous comment on this thread. > > > > > The mechanism I am suggesting for these two CRCs to provide, i.e. > > detection of error in the base context, is generic and applicable to > > all the profiles. Even though, 8-bit CRC is defined as a profile > > dependent parameter, this mechanism is general and is appropriate to > > capture it in the CR draft. Moreover, the CR draft does mention > > coverage of CRC, the following is a quote from 8-bit CRC section: > > Up to here, I do not understand what it is that you are proposing > regarding the CRCs that is not already addressed in the ROHC-CR draft. > > > "MUST cover at least the initial part of the packet ending with the > > Profile field and if present, the Base CID field" > > This would be changed to: > > "MUST cover the IR packet excluding payload" > > See Q1) above. This is exactly the same question. > > > If we can put the former text in the draft, then we can also put the > > later text in the draft. > > > > There are also other examples in the CR draft where those > > profile-specific information which are generic to multiple profiles > > are mentioned, e.g. use of a different CID than the Base CID, and > > mentioning of 7-bit CRC under Profile Specific Information. I am not > > asking to take this out. I think it is good to put these text, so the > > CR draft would serve as a better base document for the profile > > dependent documents. > > I don't think there is a contradiction here either. > > > > > > REPLICATE packet header, but the 7-bit CRC failed after > > > > > decompression, then this implies that we have a problem in > > > > > the base context. In this case only the decompressor will > > > > > send a STATIC-NACK indicating that the decompression failed > > > > > due to the problem in the base context. The compressor would > > > > > discard that base context and send IR packet. > > > > > > Only for the "one or more initial IR-REPLICATE packets", as currently > > > stated in the draft. > > > > > > "Price, Richard" wrote: > > > > > > > Page 6: "Upon reception of a NACK, the compressor may assume > > > > that the static part of the decompressor context is valid but > > > > that the dynamic part is invalid, and take actions accordingly." > > > > > > > > Again, could this also be used by the compressor as evidence > > > > that something is wrong with the base context? > > > > > > Not in this case. See previous comment. > > > > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > > > [Yousuf] Can we solve this concern by adding IR-REPLICATE > > > > > state between IR and CO state in the compressor state machine > > > > > as shown below. > > > > > > > > > > Optimistic approach / ACK ACK > > > > > +------>-------->------>------>---------+ +->-+ > > > > > | Base Ctxt Avail ACK | | | > > > > > | +----------+ +---->---->---------|| | | > > > > > | | V | vv | v > > > > > +----------+ +--------------+ +----------+ > > > > > | IR State | | IR-REP State | | CO State | > > > > > +----------+ +--------------+ +----------+ > > > > > ^ ^ | ^ | | > > > > > | +---<-----+ +-<-+ | > > > > > | STATIC-NACK Timeout/NACK | > > > > > | | > > > > > | Timeout / NACK / STATIC-NACK | > > > > > +-------<-------<-------<-------<--------+ > > > > > > > > > > I think this is also what context context replication is > > > > > doing. > > > > > > Replication is a complement to the context initialization. I do not > > > really see the relevance of adding a new state for context > > > replication. > > > > > Your original question was: > > Q2) Should we add an additional state called IR-REP? > > I fail to understand how in general this new state would be motivated. I > don't see that this is needed. For me, the IR-REPLICATE corresponds to > the IR state just like the IR does. In general, the different compressor states are just special cases of a more general rule - "don't use any information in the decompressor context until you're confident that it's arrived". The motivation for having specific states is therefore to document particular instances of this rule: how to determine the context is valid (optimistic approach, ACKS), how to determine that it's corrupt (NACKs, timeouts) and so on. We should therefore add a new state if we've introduced any new compressor logic that operates differently for "IR-REP" state than for the vanilla "IR" state. It's not clear to me whether we have done so or not - does the "selection of a base context" count as defining some state transition logic, in the sense that it defines when it's ok to move from the "IR" to "IR-REP" states? > Furthermore, states a profile specific and the ROHC-CR is not. Your > drawing seems to have the state machine of ROHC-TCP in mind. This is not necessarily a problem, as we should be focusing on the U/B-mode state machine used in ROHC-TCP. It would be a mistake to make the draft too generic, as we would then need to redefine the state transition logic all over again for each specific profile. > > This is in response to the Richard's comment you quoted below. His > > concern regarding not sending STATIC-NACK in IR state for R-mode is > > solved by the above diagram. Please also see my next comment. > > This is a different issue and I fail to see its relation with adding yet > another state. The question is: > > Q3) Can the mode be replicated? > > First, note that modes are profile specific. My opinion is that if the > ROHC-CR draft is to stay generic, than there shouldn't be anything > specific to R-mode in it. > > Second, my opinion is that the mode can't be replicated. It is nothing > that is necessary to replicate. Inaddition, this also would cause > problems with inter-profile replication. A replicated context should > start in its initial mode after replication, and the initial feedback to > the IR-REPLICATE may be used to make a mode change (FEEDBACK-2 only in > this case when ACKing) , if applicable. Wouldn't this be the simplest > thing to do? I think replicating the mode does not make sense. In theory, the "mode" could be replicated like any other field in the context. In practice, I can't see why this would buy us anything... > > > "Price, Richard" wrote: > > > > > > > Page 7: "Specifically, when the decompressor fails to validate > > > > the context following the decompression of one or more initial > > > > IR-REPLICATE packets, it MUST invalidate the context and remain > > > > in its initial state. In addition, the decompressor SHOULD send > > > > a STATIC-NACK." > > > > > > > > This logic is fine for O-mode and B-mode, but I think that > > > > different logic is required in the case of R-mode. From RFC 3095: > > > > > > > > "The decompressor SHOULD NOT send STATIC-NACK(R) when > > > > receiving an IR packet that fails the CRC check, as the > > > > compressor will stay in IR state and thus continue sending > > > > IR packets until a valid ACK is received" > > > > > > > > The above also applies to an IR-REPLICATE packet, so the > > > > decompressor SHOULD NOT send a STATIC-NACK in this case. > > > > > > In my understanding, if the CRC fails for the IR we cannot deduce > > > anything as to the validity of the context, as the 8-bit CRC is > > > calculated over information contained in the packet only. Thus in my > > > understanding the text in the draft still means that in this case the > > > decompressor would not send STATIC-NACK anyway, so in my understanding > > > this would not conflict with respect to R-mode. However, if you interpret the context replication draft as meaning "don't send a STATIC-NACK if the CRC-8 fails", then this is the same logic that is used in R-mode, but different from the logic used in O-mode. From RFC 3095: NC: - When an IR packet passes the CRC check, send an ACK(O). - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR packet has failed the CRC check, send a STATIC-NACK(O), subject to the considerations at the beginning of section 5.7.6. O-mode and R-mode take opposite approaches here, so whichever approach we select for ROHC-CR, we'll contradict at least one of these modes. > > > Furthermore, modes are actually profile dependent, not generic to all > > > profiles, so this draft should not go in more details regarding this > > > in my opinion. In cases such as the above, where different modes have different behaviours, I fully agree that we should not spend significant effort on covering the various behaviours of all possible modes. We should rather concentrate on the modes needed for ROHC-TCP, as this is still the main motivation for context replication. > > The decompressor can deduce the validity of the context using two > > CRCs in the IR-REPLICATE packet. If the context is bad, it can send > > STATIC-NACK right away as mentioned earlier. This is different from > > the text in the draft but improves the overall procedure. > > I don't see that the consequence of the text in the draft is any > different from this result, and thus I can't see the improvement from > the text in the draft either. Refer to the above explanation of the text > in the draft. If you still feel that there is improvement, please be > more specific in your comment. > > > Regarding documenting R-mode specific text in CR draft. If something > > is anticipated to be generic for R-modes and also for multiple > > profiles, then instead of repeating the common text in the multiple > > profile specific drafts it would be better to document the common > > text in the CR draft. The text from the draft implies U and B mode, > > that's where the confusion has arised. If we try to abstract the text > > too much we would loose information and cause confusion, therefore it > > is better to expand and put the R-mode also. I agree with all of the above apart from the very last line. It's certainly the case that the current context replication draft is written assuming U-mode and B-mode, which are the modes used in ROHC-TCP. Moreover, it would be a very bad idea to try and make the draft applicable to arbitrary modes (even ones that have not yet been designed), as the draft would end up basically not saying anything at all. However, this doesn't necessarily imply that we need to expand the draft to include modes other than U/B-mode. The main motivation for context replication is still ROHC-TCP, so we should avoid doing extra work to accommodate modes that aren't used by this profile. If it turns out that context replication is needed for other modes, we can always add them at a later stage. > I strongly disagree. R-mode is not a part of the generic ROHC framework, > it is rather specific to certain profiles only. This is not something > that all ROHC profiles needs to have or support. Note that R-mode also > has its own set of packet format and modes are useful to ensure that > packet type identifiers common to U/O-mode and R-mode will not be > misinterpreted, in addition to having a different feedback logic. > > However for ROHC-TCP in particular, and possibly future compression > profiles, we should hopefully limit ourselves to one set of packet > formats for the lifetime of a context. This is the path taken with > ROHC-TCP, and I believe this is also in-line with the use of the formal > notation as a tool to help us generate packet formats. The formal notation has nothing to say on the number of format sets used by a particular profile - you can use it to describe a single set only, or you can offer more than one set of packet formats. For the specific case of ROHC-TCP however, we don't currently have a reason to provide more than one set of packet formats. > Thus, and I hope others will agree with me, let's not discuss R-mode and > context replication further at this point we should not write any text > specific to R-mode in the ROHC-CR draft. I believe that the more generic > approach is to focus on a U and B mode type of operation. I agree that the draft should focus on U/B-mode at this stage. In fact, I'd prefer it if we made this explicit - currently the draft gives the impression that it defines context replication for arbitrary profiles and modes, whereas the majority of the normative text is actually specific to U/B-mode (and would need to be modified or extended to accommodate different modes such as R-mode). > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > > - I think we can improve on failure mechanism mentioned in the > > > > above two sections. The draft mentions that if the > > > > decompression of IR-REPLICATE fails, the decompressor will send > > > > STATIC NACK and the compressor MUST refrain from IR-REPLICATE, > > > > in other words use IR packets. Moving to IR means sending more > > > > bytes compared to IR-REPLICATE, hence degrading compression > > > > efficiency. If the decompression has failed due to transmission > > > > error of IR-REPLICATE (case-1), then the decompressor is > > > > unnecessarily asking for IR. It is better to ask for the > > > > retransmission of IR-REPLICATE and gain more compression > > > > efficiency. Not to mention, retransmitting an already encoded > > > > packet would be faster for the compressor. It is also possible > > > > that the decompression has failed because of the corruption in > > > > the base context (case-2). In case-2 we definitely want to move > > > > to the IR packet, since there is no way to fix it without > > > > sending full header. > > > > > > Case-1 would normally not trigger feedback. Case-2 would normally > > > trigger a NACK. An additional case is when N IR-REPLICATE received > > > (where k out of N succeed 8-bit CRC validation) would not succeed into > > > replicating a context (7-bit CRC fails for k); this would trigger > > > STATIC-NACK. > > > > > Your comment is only based on the CR daft. My above comment has > > suggested an improvement and that improvement sends feedback in > > case-1. Could you please comment on the proposed improvement. > > My comments address the ROHC-CR draft only. Also see explanations above > regarding feedack. > > > > > I'd propose that the decompressor should differentiate between > > > > the two cases. It can be done if we increase the coverage of 8- > > > > bit CRC (section 3.4.1.2)to cover static and dynamic chain > > > > also. The CRC of an IR or IR-DYN covers the whole IR packet, > > > > excluding payload (section 5.9.2 of RFC 3095). The proposed > > > > change in 8-bit CRC is more in line with the IR and IR-DYN CRC. > > > > > > This would correspond to a requirement on something that is actually > > > profile specific. The draft only put requirements on the minimal extent > > > of the coverage for the 8-bit CRC. > > > > Please see my an earlier comment on profile specifics. > > Your proposed change is in-line with the profile-specific part of the > CRC in IR and IR-DYN. The text in the ROHC-CR draft is aligned with the > profile independant part of the CRC in IR and IR-DYN (see RFC-3095 > section 5.2.3.). See Q1) above. Note however that the CR draft itself shouldn't be generic to all profiles (otherwise we'd have to cater for modes other than U/B-mode). I think that the CRC-8 coverage is a state machine issue (which may have some influence on the compressor and decompressor logic), so it would be ok to define the coverage in the ROHC-CR draft. > > > > The logic would work something like this: > > > > - if 7-bit CRC failed, send STATIC-NACK > > > > > > This would prevent the IR-REPLICATE to be used like any other compressed > > > packet. A failure to decompress one such packet does not necessarily > > > means that the static part in invalid. > > > > > I think I see your concern, we need to handle two cases as mentioned in > > section 3.3.2 of the CR draft: > > > > Case-1: 2nd para -Upon failures of one ore more initial IR-REPLICATE, > > the CR draft also sends STATIC-NACK which in turn triggers IR. It > > doesn't provides a mechanism for validating and using the static > > part, so the proposed modification doesn't have any issue with this. > > This case is only about the decompressor sending STATIC-NACK when it > could not establish a context following a number (one or more) of > _initial_ IR-REPLICATE packets - because of a faulty base context (i.e. > the static part is not known to be usable). Thus as a result it is > accurate for the compressor to start sending IRs instead. > > > Case -2: 3rd para - After successful validation of the replicated > > context, there is no need for sending STATIC-NACK, and a NACK as > > suggested in the CR draft can be used. In this way static part can be > > used, if desired. This has no issue with the proposed modification, > > as the base context has been successfully validated and the proposed > > modification won't be sending STATIC-NACK. > > In this case the draft states is also correct, right? > > > > > - if 8-bit CRC fails, send another NACK (let's call it REP- > > > > NACK). > > > > > > The 8-bit CRC protects the integrity of the IR packet itself. while > > > feedback is used to convey information regarding the state of the > > > context. In my opinion, it would be not be proper to define a new > > > feedback type to report a transmission error instead of considering the > > > state of the context. > > > > > > > I think that is an incorrect description of the purpose of the new > > feedback type. The feedback is not reporting a transmission error. It > > is reporting why the state of the context can't be changed. The > > information is used for increasing robustness and improving > > compression efficiency, as mentioned earlier in this email. > > If I rephrase your comment, you mean that the new feedback type would > convey information regarding why the context could not be updated, > correct? A context is updated when decompression succeeds (i.e. when the > CRC validates the decompressed header - in this case when the CRC-7 of > the IR-REPLICATE succeeds). When the CRC-8 of the IR-REPLICATE fails, it > does not provide the decompressor with any other information that there > has been a transmission error. Specifically, decompression is not even > attempted, and the error might even be on the CID field, base CID field > or profile field of the IR-REPLICATE - thus in this case what this > option would transmit cannot relate to the state of the context (neither > to the state of the base context). And I don't believe that a new > feedback option that carries information that does not relate to the > state of the context is justified. > > If I misunderstand your comment, please clarify it. Thanks! I think that Yousuf's suggestion makes theoretical sense if you consider the REP-NACK to be a particular type of STATIC-NACK (i.e. an option in the FEEDBACK-2 format). What the REP-NACK essentially does is to say that the static context is not valid or not established (same as the STATIC-NACK), but gives a particular reason for why this is the case: namely that there has been a transmission error. This information may potentially be useful to the compressor - if it knows that the context is invalid because of a transmission error rather than an error in the base context, it can take the appropriate actions (e.g. sending more IR-REPLICATE packets, rather than giving up and sending a basic IR packet). In practice however, we need to weigh up the potential benefits of introducing a new feedback option relative to the extra effort required. In the case of ROHC-TCP, will transmission errors be sufficiently common to make this extra feedback option worthwhile? > > > > We could differentiate a REP-NACK from a regular NACK by using > > > > feedback options in the FEEDBACK-2 format and make this option > > > > available to other profiles besides TCP. We could have used > > > > > > In my opinion, this is not necessary. Also, I would be reluctant to > > > define a new feedback option if I can avoid it. > > > > > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jun 19 19:01:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24453 for ; Thu, 19 Jun 2003 19:01:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JN13530873 for rohc-archive@odin.ietf.org; Thu, 19 Jun 2003 19:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T8Ot-00081s-7r for rohc-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 19:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24425 for ; Thu, 19 Jun 2003 19:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T8MZ-0004Rx-00 for rohc-web-archive@ietf.org; Thu, 19 Jun 2003 18:58:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T8MY-0004Ru-00 for rohc-web-archive@ietf.org; Thu, 19 Jun 2003 18:58:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T8Oq-00081W-IF; Thu, 19 Jun 2003 19:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T8OS-00080x-1S for rohc@optimus.ietf.org; Thu, 19 Jun 2003 19:00:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24411 for ; Thu, 19 Jun 2003 19:00:31 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T8M8-0004Rn-00 for rohc@ietf.org; Thu, 19 Jun 2003 18:58:12 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19T8M7-0004Rk-00 for rohc@ietf.org; Thu, 19 Jun 2003 18:58:11 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JN0VG03571 for ; Thu, 19 Jun 2003 18:00:31 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Jun 2003 18:00:29 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 15:59:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Thu, 19 Jun 2003 17:59:10 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139886C@daebe004.americas.nokia.com> Thread-Topic: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Thread-Index: AcM2jrngV5UbaG1BSwOvcE+vI4mL6QAC4lzw To: , Cc: X-OriginalArrivalTime: 19 Jun 2003 22:59:12.0174 (UTC) FILETIME=[661EACE0:01C336B6] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA24453 Hi Ghyslain and Richard, Thanks for the discussion. Please see my comments below. The lines prefixed by "> >" are from Ghyslain, and by ">" are from Richard. Cheers, Yousuf > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Thursday, June 19, 2003 1:14 PM > To: 'Ghyslain Pelletier'; Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and > some topics to be discussed) > > > > I appreciate your comments. Those suggestions that I do not > favor are > > because I do not see (or understand) their motivations. Obviously in > > such case it would be useful if someone else on the list joins in to > > help us out. > > I guess this means me ;-) > > > See further comments inline. > > > > /Ghyslain > > > > Ghyslain Pelletier, Dipl. Ing. > > Wireless IP Optimizations > > AWARE - Advanced Wireless Algorithm Research > > Ericsson Research, Corporate Unit > > > > Ericsson AB, Laboratoriegränd 11 > > Box 920, S-97128 Luleå, SWEDEN > > Phone : +46 (0) 920 20 24 32 > > Mobile: +46 (0) 706 09 27 73 > > Ghyslain.Pelletier@epl.ericsson.se > > http://www.ericsson.com > > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > Hi Ghyslain, > > > > > > In summary, your comments are related to the modifications I > > > proposed for the ROHC-CR feedback. I understand that you are not > > > favoring the proposed modifications, but I do not understand the > > > justification for it. > > > > > > The proposed modifications doesn't add any bits in the > IR-REPLICATE > > > packet, it only changes the 8-bit CRC coverage. > > > > The draft is currently written to be generic and reused by > any profiles. > > Because the IR-REPLICATE is a ROHC IR packet, the minimal > coverage of > > this CRC must follow RFC-3095. RFC-3095 also states that > this coverage > > may be extended to cover more (such as including any > information that > > initializes the context), but that this should be defined on a > > per-profile basis. I cannot think of any specific reason > why this was > > specified like this, however I have chosen to do the same > when writing > > ROHC-CR. So, trying to clarify your comments and if I understand > > correctly, your question regarding the CRC-8 is thus: > > > > Q1) should we mandate that every profile supporting ROHC-CR > calculates > > the CRC-8 over the entire IR-REPLICATE packet, excluding the > > payload? > > > > Regarding this, I still favor that each profile specify this itself. > > However, I have no strong feelings about this, as > ultimately I suspect > > that any profile would do just that. > > I don't see any reason *not* to specify the CRC-8 coverage in > the context > replication draft, as we're already specifying features that > are far more > profile-specific than this (which is by no means a bad thing!). > I have the same opinion, specify what CRC-8 covers. > > The coverage of the 8-bit CRC in the IR-REPLICATE > > > > > It provides > > > mechanism for detecting bad base context, only for the initial > > > IR-REPLICATE packets and not after successful validation of the > > > context (please see my 2nd last embedded comment below). > > > > This is were I fail to follow you. In my understanding, the > 8-bit CRC - > > calculated over information contained in the IR packet - is not what > > provides the "mechanism for detecting a bad base context". > This CRC will > > only allow you to detect that there has been an error in > the received > > packet (transmission error), and since the information > covered by this > > CRC includes CID it is difficult to take proper action more than to > > discard the packet. > > Another possible action upon receiving an IR packet which fails the > 8-bit CRC is to send a STATIC-NACK (e.g. O-mode from RFC 3095 > does this). > It's not 100% guaranteed that the STATIC-NACK will refer to > the correct CID, > but this is no different from the case where a CRC over the > decompressed > header fails. I am sorry if I was not clear earlier. Action on 8-bit CRC (coverage complete IR-REPLICATE header) is taken after decompressor fails 7-bit CRC (coverage original header) test. If 7-bit CRC failed but 8-bit CRC passed, the decompressor sends STATIC-NACK. It is sure now that the base context is bad. If 7-bit CRC failed and 8-bit CRC also fails, then send a NACK (R-mode) or ignore it and wait for subsequent IR-RELICATE (U/O-mode). 8-bit CRC by itself is not considered for decision. Please see my next comment also. > > > > If we don't > > > incorporate the proposed modifications, in case of a bad context: > > > > > > 1) the compressor would continue to send N IR-REPLICATE > packets and > > > eventually send IR packet. There will be N-1 unnecessary > > > transmission of IR-REPLICATE packets. > > It's not the case that a bad base context will cause N-1 unnecessary > transmissions of an IR-REPLICATE packet. Instead the CRC-7 will fail, > causing the decompressor to send a STATIC-NACK and the compressor to > transit back to sending vanilla IR packets. > > > When the CRC-8 of the IR-REPLICATE fails to verify, the decompressor > > does not take any different actions than those stated in RFC-3095, > > section 5.2.6 (see item #10). Maybe this needs to be > clarified? I could > > add a section "initial decompressor processing", that would add a > > paragraph identical to item #10? > > > > The CRC that is used for detecting a faulty context is the > 7-bit CRC for > > which ROHC-CR states that its presence is mandatory within > the "profile > > specific information" of the IR-REPLICATE packet. The CRC-7 is > > calculated over the original, uncompressed header and thus verifies > > decompressor (validity of the context). > > > > In summary, the CRC-8 is present to make sure that an IR-REPLICATE > > initializing a new context using replication has had its > CID and profile > > validated, and that the information that initializes the context was > > received without error. Since with replication some of this > information > > is sent compressed already within the first IR-REPLICATE, > the CRC-7 is > > necessary to verify the decompression - thus in turn to > verifying that > > replication was successful (i.e. the base context used was ok!). See > > ROHC-CR section 3.1. > > > > Now, when the CRC-7 in the IR-REPLICATE fails to verify the > decompressed > > header, this is when the decompressor might generate > feedback. Section > > 3.3.2 states that: > > > > 1) ACK should be sent when one or more IR-REPLICATE succeeds CRC-7 > > validation, i.e. decompression succeeded -> context is ok. > > > > 2) NACK should be sent when one or more IR-REPLICATE fails CRC-7 > > validation in the following case: > > o a context had been successfully established prior to > the packet(s) > > for which decompression failed > > I.e. case A: > > A valid context had been successfully established for that > > flow, but decompression failed for one or more packets -> context > > went from ok to not ok and is now a "bad context". > > > > 3) STATIC-NACK should be sent when one or more IR-REPLICATE fails > > CRC-7 validation in the following case: > > o no context has yet been established for this flow prior to the > > packet(s) for which decompression failed. > > I.e. case B: > > No valid context has been established for that flow, and > > decompression fails for one or more packets -> context never > > established and is not suited to be a base context > > (is a "bad context" for replication). > > > > Thus, case A is not triggering the sending of IRs, case B does. > > I agree with you for items 1) and 2). The case B is the one I want to differ. The decompression failure doesn't always mean "bad context". Let me explain, we have 7-bit CRC that covers original header and 8-bit CRC that covers the IR-REPLICATE packet header excluding payload (this is with the proposed modification). A decompressor receives an initial IR-REPLICATE. It decompresses the packet by using the referred base context and the static/dynamic replication chains provided in the IR-REPLICATE message. After decompression it calculates 7-bit CRC and fails the 7-bit CRC test. There are two sources of error, either the referred base context is bad (case B-1) or the static/dynamic replication chain provided in the IR-REPLICATE is bad (case B-2). Let's say if the static/dynamic chain is bad, then there is no justification for labeling this context as the "bad context". Here the 8-bit CRC comes handy, if it passes CRC check then the decompressor knows that the static/dynamic chains are fine but the context is bad, and sends STATIC NACK. The mechanism I proposed substracts out case B-2 from case B. > > > 2) when a base context gets corrupted, it may continue to be used > > > for the other context replications, and each of those would fail N > > > IR-REPLICATE packets. There will be (num of bad base contexts)* > > > (N-1) unnecessary transmission of IR-REPLICATE packets > > > > Here I fail to understand how this could be. A base context > that gets > > corrupted will not be used for replicating other context, > as it would > > have been NACKed and thus fails the requirements for the > selection of a > > base context (i.e. must have been ACKed and valid at the > compressor at > > the time of replication). > > There are definitely some cases where the base context can > get corrupted > and still be used for replicating other contexts (for > example, it might > become corrupted after being ACKed). However, I think that > the existing > NACK and STATIC-NACK mechanisms are sufficient to detect these cases > (in particular, the CRC-7 would catch the faulty base context > and cause > a NACK or STATIC-NACK to be sent). > CRC-7 by itself can't differentiate whether the error is in the base context or the static/dynamic chains of IR-REPLICATE. It is on the original header and can catch error in the new replicated context, which is formed by the aggregation of the base context and the received static/dynamic chains. If we only use CRC-7 we'd be discarding base contexts unnecessarily, and causing transmission of IR for case B-2. Please see my previous comment. > > > Thus, with proposed modifications we add robustness and > compression > > > efficiency. Could you tell me why you think the proposed > > > modifications for feedback is unnecessary? > > > > > > Also, please find my specific comments below. > > > > > > Regards, > > > Yousuf > > > > > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > > > > > [Yousuf] I think it is possible to use STATIC-NACK for > > > > > > indicating corruption in the base context, and another NACK > > > > > > for indicating transmission error in IR-REPLICATE packet. We > > > > > > > > In my understanding, ACKs and NACKs are used to > transmit information > > > > regarding the state of the context (potentially at a > specific packet in > > > > the SN space), not to provide information regarding the > state of the > > > > transmission. Therefore I do not really understand why > there would be a > > > > need to define a new feedback option to indicate > transmission error in > > > > the IR-REPLICATE packet. > > > > > > > The need is to identify why the state of the context can't be > > > changed? If the state of the context can't be changed because the > > > base context is bad, the compressor could stop using the bad base > > > context and start sending the IR packet. This helps in adding > > > robustness and compression efficiency on the CR procedure, please > > > also see my earlier comment. > > I think that the compressor can stop using a bad base context > and switch > to IR packets, using the NACK and STATIC-NACK mechanisms that > are already > available. If the compressor receives a NACK or STATIC-NACK > then it knows > that something is wrong with the context, so it must be > refreshed using an > IR(-DYN) packet. The use of only 7-bit CRC for triggering IR(-DYN) is not good, please see my earlier comment. > > > What do you mean "why the state of the context can't be > changed"? Do you > > mean that it failed to validate the decompression (CRC-7) > and thus the > > packet can't update the context? > > > > Your original request is to add "another NACK for indicating > > transmission error in IR-REPLICATE packet". This is what I > fail to see a > > justification for. As I previously explained, my > understanding is that > > feedback with ROHC is meant to carry information regarding > the state of > > the decompressor context back to the compressor, not to carry > > information about transmission errors. Identifying why a > context becomes > > invalid and which of STATIC-NACK or NACK should be sent is explained > > above. Recall that both FEEDBACK-1 and FEEDBACK-2 carries > SN bits that > > corresponds to the sequence number of the header (e.g. IR-REPLICATE) > > that caused the feedback information to be sent. If no > sequence number > > can be determined, then the feedback carries the > SN-NOT-VALID option. > > This is useful for the compressor to determine the cause of > the problem. For the feedback message, the request for another NACK is mode specific and is for R mode. For U/O mode we don't need to send explicit NACK. The confusion is that we try to do profile independent CR discussion using a draft which is profile dependent. > > > > > > > > have two CRCs. 7-bit CRC covers the original uncompressed > > > > > > header and the 8-bit CRC covers the IR packet including > > > > > > static and dynamic chain (this is with the change > proposed in > > > > > > my last email). If 8-bit CRC verifies integrity of IR- > > > > > > > > The extent of the coverage of the 8-bit CRC (other than > the minimal > > > > coverage required by RFC-3095) is profile dependent. It would be > > > > unappropriate to define it as to include chains in this > draft, unless we > > > > make context replication profile-specific. This is also > in line with one > > > > of Richard's previous comment on this thread. > > > > > > > The mechanism I am suggesting for these two CRCs to provide, i.e. > > > detection of error in the base context, is generic and > applicable to > > > all the profiles. Even though, 8-bit CRC is defined as a profile > > > dependent parameter, this mechanism is general and is > appropriate to > > > capture it in the CR draft. Moreover, the CR draft does mention > > > coverage of CRC, the following is a quote from 8-bit CRC section: > > > > Up to here, I do not understand what it is that you are proposing > > regarding the CRCs that is not already addressed in the > ROHC-CR draft. > > My proposal for CRC is mentioned in the next four lines. > > > "MUST cover at least the initial part of the packet > ending with the > > > Profile field and if present, the Base CID field" > > > This would be changed to: > > > "MUST cover the IR packet excluding payload" > > > > See Q1) above. This is exactly the same question. > > > > > If we can put the former text in the draft, then we can > also put the > > > later text in the draft. > > > > > > There are also other examples in the CR draft where those > > > profile-specific information which are generic to > multiple profiles > > > are mentioned, e.g. use of a different CID than the Base CID, and > > > mentioning of 7-bit CRC under Profile Specific > Information. I am not > > > asking to take this out. I think it is good to put these > text, so the > > > CR draft would serve as a better base document for the profile > > > dependent documents. > > > > I don't think there is a contradiction here either. > > > > > > > > REPLICATE packet header, but the 7-bit CRC failed after > > > > > > decompression, then this implies that we have a problem in > > > > > > the base context. In this case only the decompressor will > > > > > > send a STATIC-NACK indicating that the decompression failed > > > > > > due to the problem in the base context. The compressor would > > > > > > discard that base context and send IR packet. > > > > > > > > Only for the "one or more initial IR-REPLICATE > packets", as currently > > > > stated in the draft. > > > > > > > > "Price, Richard" wrote: > > > > > > > > > Page 6: "Upon reception of a NACK, the compressor may assume > > > > > that the static part of the decompressor context is valid but > > > > > that the dynamic part is invalid, and take actions > accordingly." > > > > > > > > > > Again, could this also be used by the compressor as evidence > > > > > that something is wrong with the base context? > > > > > > > > Not in this case. See previous comment. > > > > > > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > > > > > [Yousuf] Can we solve this concern by adding IR-REPLICATE > > > > > > state between IR and CO state in the compressor > state machine > > > > > > as shown below. > > > > > > > > > > > > Optimistic approach / ACK ACK > > > > > > +------>-------->------>------>---------+ +->-+ > > > > > > | Base Ctxt Avail ACK | | | > > > > > > | +----------+ +---->---->---------|| | | > > > > > > | | V | vv | v > > > > > > +----------+ +--------------+ +----------+ > > > > > > | IR State | | IR-REP State | | CO State | > > > > > > +----------+ +--------------+ +----------+ > > > > > > ^ ^ | ^ | | > > > > > > | +---<-----+ +-<-+ | > > > > > > | STATIC-NACK Timeout/NACK | > > > > > > | | > > > > > > | Timeout / NACK / STATIC-NACK | > > > > > > +-------<-------<-------<-------<--------+ > > > > > > > > > > > > I think this is also what context context replication is > > > > > > doing. > > > > > > > > Replication is a complement to the context > initialization. I do not > > > > really see the relevance of adding a new state for context > > > > replication. > > > > > > > > Your original question was: > > > > Q2) Should we add an additional state called IR-REP? > > > > I fail to understand how in general this new state would be > motivated. I > > don't see that this is needed. For me, the IR-REPLICATE > corresponds to > > the IR state just like the IR does. > > In general, the different compressor states are just special > cases of a > more general rule - "don't use any information in the > decompressor context > until you're confident that it's arrived". The motivation for having > specific states is therefore to document particular instances > of this rule: > how to determine the context is valid (optimistic approach, > ACKS), how to > determine that it's corrupt (NACKs, timeouts) and so on. > > We should therefore add a new state if we've introduced any > new compressor > logic that operates differently for "IR-REP" state than for > the vanilla > "IR" state. It's not clear to me whether we have done so or > not - does the > "selection of a base context" count as defining some state > transition logic, > in the sense that it defines when it's ok to move from the > "IR" to "IR-REP" > states? > I think we have introduced a new logic with context replication for IR-REP then IR. It uses a base context that has been acknowledged. It uses a unique packet format for encoding. It may send STATIC-NACK. > > Furthermore, states a profile specific and the ROHC-CR is not. Your > > drawing seems to have the state machine of ROHC-TCP in mind. > > This is not necessarily a problem, as we should be focusing > on the U/B-mode > state machine used in ROHC-TCP. It would be a mistake to make > the draft too > generic, as we would then need to redefine the state > transition logic all > over again for each specific profile. I have used ROHC-TCP diagram to draw it. My main point is that should we add an "IR-REP" state or not? I have given my comments on this above. I also think that keeping this ROHC-CR document too generic so it won't have any substance in it to depict a meaningful picture is not a good idea. > > > > This is in response to the Richard's comment you quoted below. His > > > concern regarding not sending STATIC-NACK in IR state for > R-mode is > > > solved by the above diagram. Please also see my next comment. > > > > This is a different issue and I fail to see its relation > with adding yet > > another state. The question is: > > The relation is this, we can't send STATIC-NACK in IR state but we can send STATIC-NACK in IR-REP state. So by adding IR-REP state, we are keeping whatever ROHC has decided about IR state. Any new function or logic is executed from IR-REP state. > > Q3) Can the mode be replicated? > > > > First, note that modes are profile specific. My opinion is > that if the > > ROHC-CR draft is to stay generic, than there shouldn't be anything > > specific to R-mode in it. After reading the complete response from both of you, I think it would be better if we don't keep ROHC-CR generic, and make it specific for ROHC-TCP. How about changing it to ROHC-TCP-CR? In this way we will be able to put enough details and avoid unnecessary abstraction and confusion resulting from it. We agree that we need to do CR for ROHC-TCP first, so let's do this. IMO it is dangerous if we write this ROHC-CR implicitly assuming TCP and then try to mandate it as a generic CR solution for all the profiles. > > > > Second, my opinion is that the mode can't be replicated. It > is nothing > > that is necessary to replicate. Inaddition, this also would cause > > problems with inter-profile replication. A replicated context should > > start in its initial mode after replication, and the > initial feedback to > > the IR-REPLICATE may be used to make a mode change > (FEEDBACK-2 only in > > this case when ACKing) , if applicable. Wouldn't this be > the simplest > > thing to do? I think replicating the mode does not make sense. > > In theory, the "mode" could be replicated like any other field in the > context. In practice, I can't see why this would buy us anything... The issue behind above disscussion is not about replicating a "mode", but the issue is that are we going to document how context replication would work in different modes? If yes, then where? in ROHC-CR or individual profiles. I have already suggested to have ROHC-TCP-CR and documenting in it whatever mode is relevant to TCP. > > > > > "Price, Richard" wrote: > > > > > > > > > Page 7: "Specifically, when the decompressor fails to validate > > > > > the context following the decompression of one or more initial > > > > > IR-REPLICATE packets, it MUST invalidate the context > and remain > > > > > in its initial state. In addition, the decompressor > SHOULD send > > > > > a STATIC-NACK." > > > > > > > > > > This logic is fine for O-mode and B-mode, but I think that > > > > > different logic is required in the case of R-mode. > From RFC 3095: > > > > > > > > > > "The decompressor SHOULD NOT send STATIC-NACK(R) when > > > > > receiving an IR packet that fails the CRC check, as the > > > > > compressor will stay in IR state and thus > continue sending > > > > > IR packets until a valid ACK is received" > > > > > > > > > > The above also applies to an IR-REPLICATE packet, so the > > > > > decompressor SHOULD NOT send a STATIC-NACK in this case. > > > > > > > > In my understanding, if the CRC fails for the IR we > cannot deduce > > > > anything as to the validity of the context, as the 8-bit CRC is > > > > calculated over information contained in the packet > only. Thus in my > > > > understanding the text in the draft still means that in > this case the > > > > decompressor would not send STATIC-NACK anyway, so in > my understanding > > > > this would not conflict with respect to R-mode. > > However, if you interpret the context replication draft as > meaning "don't > send a STATIC-NACK if the CRC-8 fails", then this is the same > logic that is > used in R-mode, but different from the logic used in O-mode. > From RFC 3095: > > NC: - When an IR packet passes the CRC check, send an ACK(O). > - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR > packet has failed the CRC check, send a STATIC-NACK(O), > subject to the considerations at the beginning of section > 5.7.6. > > O-mode and R-mode take opposite approaches here, so whichever approach > we select for ROHC-CR, we'll contradict at least one of these modes. > > > > > Furthermore, modes are actually profile dependent, not > generic to all > > > > profiles, so this draft should not go in more details > regarding this > > > > in my opinion. > > In cases such as the above, where different modes have > different behaviours, > I fully agree that we should not spend significant effort on > covering the > various behaviours of all possible modes. We should rather > concentrate on > the modes needed for ROHC-TCP, as this is still the main > motivation for > context replication. > > > > The decompressor can deduce the validity of the context using two > > > CRCs in the IR-REPLICATE packet. If the context is bad, > it can send > > > STATIC-NACK right away as mentioned earlier. This is > different from > > > the text in the draft but improves the overall procedure. > > > > I don't see that the consequence of the text in the draft is any > > different from this result, and thus I can't see the > improvement from > > the text in the draft either. Refer to the above > explanation of the text > > in the draft. If you still feel that there is improvement, please be > > more specific in your comment. I have explained the improvement by using case B-1 and case B-2 earlier. My first few comments in this response have all the specifics. > > > > > Regarding documenting R-mode specific text in CR draft. > If something > > > is anticipated to be generic for R-modes and also for multiple > > > profiles, then instead of repeating the common text in > the multiple > > > profile specific drafts it would be better to document the common > > > text in the CR draft. The text from the draft implies U > and B mode, > > > that's where the confusion has arised. If we try to > abstract the text > > > too much we would loose information and cause confusion, > therefore it > > > is better to expand and put the R-mode also. > > I agree with all of the above apart from the very last line. > It's certainly > the case that the current context replication draft is > written assuming > U-mode and B-mode, which are the modes used in ROHC-TCP. Moreover, it > would be a very bad idea to try and make the draft applicable > to arbitrary > modes (even ones that have not yet been designed), as the > draft would end > up basically not saying anything at all. > > However, this doesn't necessarily imply that we need to > expand the draft > to include modes other than U/B-mode. The main motivation for context > replication is still ROHC-TCP, so we should avoid doing extra work to > accommodate modes that aren't used by this profile. If it > turns out that > context replication is needed for other modes, we can always > add them at > a later stage. > I agree with you. But also, change ROHC-CR draft to ROHC-TCP-CR draft. > > I strongly disagree. R-mode is not a part of the generic > ROHC framework, > > it is rather specific to certain profiles only. This is not > something > > that all ROHC profiles needs to have or support. Note that > R-mode also > > has its own set of packet format and modes are useful to ensure that > > packet type identifiers common to U/O-mode and R-mode will not be > > misinterpreted, in addition to having a different feedback logic. > > > > However for ROHC-TCP in particular, and possibly future compression > > profiles, we should hopefully limit ourselves to one set of packet > > formats for the lifetime of a context. This is the path taken with > > ROHC-TCP, and I believe this is also in-line with the use > of the formal > > notation as a tool to help us generate packet formats. > > The formal notation has nothing to say on the number of > format sets used > by a particular profile - you can use it to describe a single > set only, > or you can offer more than one set of packet formats. For the specific > case of ROHC-TCP however, we don't currently have a reason to provide > more than one set of packet formats. > > > Thus, and I hope others will agree with me, let's not > discuss R-mode and > > context replication further at this point we should not > write any text > > specific to R-mode in the ROHC-CR draft. I believe that the > more generic > > approach is to focus on a U and B mode type of operation. > > I agree that the draft should focus on U/B-mode at this > stage. In fact, I'd > prefer it if we made this explicit - currently the draft > gives the impression > that it defines context replication for arbitrary profiles > and modes, whereas > the majority of the normative text is actually specific to > U/B-mode (and would > need to be modified or extended to accommodate different > modes such as R-mode). I have no problem with this. The document should explicity say that it is applicable to ROHC-TCP and its modes. > > > > > Yousuf.Saifullah@nokia.com wrote: > > > > > > > > > - I think we can improve on failure mechanism mentioned in the > > > > > above two sections. The draft mentions that if the > > > > > decompression of IR-REPLICATE fails, the decompressor > will send > > > > > STATIC NACK and the compressor MUST refrain from IR-REPLICATE, > > > > > in other words use IR packets. Moving to IR means sending more > > > > > bytes compared to IR-REPLICATE, hence degrading compression > > > > > efficiency. If the decompression has failed due to > transmission > > > > > error of IR-REPLICATE (case-1), then the decompressor is > > > > > unnecessarily asking for IR. It is better to ask for the > > > > > retransmission of IR-REPLICATE and gain more compression > > > > > efficiency. Not to mention, retransmitting an already encoded > > > > > packet would be faster for the compressor. It is also possible > > > > > that the decompression has failed because of the corruption in > > > > > the base context (case-2). In case-2 we definitely > want to move > > > > > to the IR packet, since there is no way to fix it without > > > > > sending full header. > > > > > > > > Case-1 would normally not trigger feedback. Case-2 > would normally > > > > trigger a NACK. An additional case is when N > IR-REPLICATE received > > > > (where k out of N succeed 8-bit CRC validation) would > not succeed into > > > > replicating a context (7-bit CRC fails for k); this > would trigger > > > > STATIC-NACK. > > > > > > > Your comment is only based on the CR daft. My above comment has > > > suggested an improvement and that improvement sends feedback in > > > case-1. Could you please comment on the proposed improvement. > > > > My comments address the ROHC-CR draft only. Also see > explanations above > > regarding feedack. > > > > > > > I'd propose that the decompressor should differentiate between > > > > > the two cases. It can be done if we increase the > coverage of 8- > > > > > bit CRC (section 3.4.1.2)to cover static and dynamic chain > > > > > also. The CRC of an IR or IR-DYN covers the whole IR packet, > > > > > excluding payload (section 5.9.2 of RFC 3095). The proposed > > > > > change in 8-bit CRC is more in line with the IR and > IR-DYN CRC. > > > > > > > > This would correspond to a requirement on something > that is actually > > > > profile specific. The draft only put requirements on > the minimal extent > > > > of the coverage for the 8-bit CRC. > > > > > > Please see my an earlier comment on profile specifics. > > > > Your proposed change is in-line with the profile-specific > part of the > > CRC in IR and IR-DYN. The text in the ROHC-CR draft is > aligned with the > > profile independant part of the CRC in IR and IR-DYN (see RFC-3095 > > section 5.2.3.). See Q1) above. > > Note however that the CR draft itself shouldn't be generic to > all profiles > (otherwise we'd have to cater for modes other than U/B-mode). > I think that > the CRC-8 coverage is a state machine issue (which may have > some influence > on the compressor and decompressor logic), so it would be ok > to define the > coverage in the ROHC-CR draft. > > > > > > The logic would work something like this: > > > > > - if 7-bit CRC failed, send STATIC-NACK > > > > > > > > This would prevent the IR-REPLICATE to be used like any > other compressed > > > > packet. A failure to decompress one such packet does > not necessarily > > > > means that the static part in invalid. > > > > > > > I think I see your concern, we need to handle two cases > as mentioned in > > > section 3.3.2 of the CR draft: > > > > > > Case-1: 2nd para -Upon failures of one ore more initial > IR-REPLICATE, > > > the CR draft also sends STATIC-NACK which in turn triggers IR. It > > > doesn't provides a mechanism for validating and using the static > > > part, so the proposed modification doesn't have any issue > with this. > > > > This case is only about the decompressor sending STATIC-NACK when it > > could not establish a context following a number (one or more) of > > _initial_ IR-REPLICATE packets - because of a faulty base > context (i.e. > > the static part is not known to be usable). Thus as a result it is > > accurate for the compressor to start sending IRs instead. > > > > > Case -2: 3rd para - After successful validation of the replicated > > > context, there is no need for sending STATIC-NACK, and a NACK as > > > suggested in the CR draft can be used. In this way static > part can be > > > used, if desired. This has no issue with the proposed > modification, > > > as the base context has been successfully validated and > the proposed > > > modification won't be sending STATIC-NACK. > > > > In this case the draft states is also correct, right? > > > > > > > - if 8-bit CRC fails, send another NACK (let's call it REP- > > > > > NACK). > > > > > > > > The 8-bit CRC protects the integrity of the IR packet > itself. while > > > > feedback is used to convey information regarding the > state of the > > > > context. In my opinion, it would be not be proper to > define a new > > > > feedback type to report a transmission error instead of > considering the > > > > state of the context. > > > > > > > > > > I think that is an incorrect description of the purpose of the new > > > feedback type. The feedback is not reporting a > transmission error. It > > > is reporting why the state of the context can't be changed. The > > > information is used for increasing robustness and improving > > > compression efficiency, as mentioned earlier in this email. > > > > If I rephrase your comment, you mean that the new feedback > type would > > convey information regarding why the context could not be updated, > > correct? A context is updated when decompression succeeds > (i.e. when the > > CRC validates the decompressed header - in this case when > the CRC-7 of > > the IR-REPLICATE succeeds). When the CRC-8 of the > IR-REPLICATE fails, it > > does not provide the decompressor with any other > information that there > > has been a transmission error. Specifically, decompression > is not even > > attempted, and the error might even be on the CID field, > base CID field > > or profile field of the IR-REPLICATE - thus in this case what this > > option would transmit cannot relate to the state of the > context (neither > > to the state of the base context). And I don't believe that a new > > feedback option that carries information that does not relate to the > > state of the context is justified. > > > > If I misunderstand your comment, please clarify it. Thanks! > > I think that Yousuf's suggestion makes theoretical sense if > you consider > the REP-NACK to be a particular type of STATIC-NACK (i.e. an option in > the FEEDBACK-2 format). What the REP-NACK essentially does is > to say that > the static context is not valid or not established (same as > the STATIC-NACK), > but gives a particular reason for why this is the case: > namely that there > has been a transmission error. This information may > potentially be useful > to the compressor - if it knows that the context is invalid because of > a transmission error rather than an error in the base > context, it can take > the appropriate actions (e.g. sending more IR-REPLICATE > packets, rather > than giving up and sending a basic IR packet). > > In practice however, we need to weigh up the potential benefits of > introducing a new feedback option relative to the extra > effort required. > In the case of ROHC-TCP, will transmission errors be > sufficiently common > to make this extra feedback option worthwhile? > The transmission errors are common in lossy links. That's where ROHC solutions will be used most. Let me also repeat that this feedback is not needed for U/O-mode. It would be needed for R-mode. In U/O-mode the compressor may continue to send IR-REPLICATE. > > > > > We could differentiate a REP-NACK from a regular NACK by using > > > > > feedback options in the FEEDBACK-2 format and make this option > > > > > available to other profiles besides TCP. We could have used > > > > > > > > In my opinion, this is not necessary. Also, I would be > reluctant to > > > > define a new feedback option if I can avoid it. > > > > > > > > > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > 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. > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jun 20 05:56:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23358 for ; Fri, 20 Jun 2003 05:56:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K9u2B29632 for rohc-archive@odin.ietf.org; Fri, 20 Jun 2003 05:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIck-0007hr-PK for rohc-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 05:56:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23328 for ; Fri, 20 Jun 2003 05:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TIaO-0001Ak-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 05:53:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TIaN-0001Ah-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 05:53:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIcj-0007hV-DA; Fri, 20 Jun 2003 05:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TIcR-0007hG-1o for rohc@optimus.ietf.org; Fri, 20 Jun 2003 05:55:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23321 for ; Fri, 20 Jun 2003 05:55:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TIa4-0001Ae-00 for rohc@ietf.org; Fri, 20 Jun 2003 05:53:16 -0400 Received: from [203.199.54.8] (helo=ltitlout.lntinfotech.com) by ietf-mx with esmtp (Exim 4.12) id 19TIa3-0001AY-00 for rohc@ietf.org; Fri, 20 Jun 2003 05:53:15 -0400 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2003062015193230:2058 ; Fri, 20 Jun 2003 15:19:32 +0530 To: rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jagan S" Date: Fri, 20 Jun 2003 13:04:03 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/20/2003 03:17:29 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 06/20/2003 03:19:32 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 06/20/2003 03:27:52 PM, Serialize complete at 06/20/2003 03:27:52 PM Content-type: text/plain; charset=us-ascii Subject: [rohc] UDVM working code Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi., I currently working on implementation of SigComp in Linux. Can anybody provide me the links, where can I get the source code/library for UDVM. ( am I right in asking this question.?....plz correct me, if I am wrong & also help me in using correct UDVM for the experiment). Thanx in advance - Jagan _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jun 20 07:36:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26620 for ; Fri, 20 Jun 2003 07:36:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBa2M19823 for rohc-archive@odin.ietf.org; Fri, 20 Jun 2003 07:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBW-00059c-AB for rohc-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 07:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26549 for ; Fri, 20 Jun 2003 07:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TK9A-0001id-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 07:33:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TK9A-0001ia-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 07:33:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBV-00057d-3Y; Fri, 20 Jun 2003 07:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKBB-00054v-45 for rohc@optimus.ietf.org; Fri, 20 Jun 2003 07:35:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26444; Fri, 20 Jun 2003 07:35:39 -0400 (EDT) Message-Id: <200306201135.HAA26444@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 07:35:39 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-context-replication-00.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC):Context Replication for ROHC Profiles Author(s) : G. Pelletier Filename : draft-ietf-rohc-context-replication-00.txt Pages : 21 Date : 2003-6-19 This document defines context replication, a complement to the context initialization procedure found in ROHC (Robust Header Compression) [RFC-3095]. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure, and may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as for example short- lived TCP flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-context-replication-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-ietf-rohc-context-replication-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-ietf-rohc-context-replication-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: <2003-6-19154431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-context-replication-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-context-replication-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154431.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jun 20 12:32:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16336 for ; Fri, 20 Jun 2003 12:32:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KGW2V08625 for rohc-archive@odin.ietf.org; Fri, 20 Jun 2003 12:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOny-0002F2-ID for rohc-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 12:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16329 for ; Fri, 20 Jun 2003 12:31:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TOnx-0006TI-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 12:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TOnw-0006TF-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 12:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOnx-0002Eh-9R; Fri, 20 Jun 2003 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOnh-0002EW-7H for rohc@optimus.ietf.org; Fri, 20 Jun 2003 12:31:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16320 for ; Fri, 20 Jun 2003 12:31:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TOnf-0006T0-00 for rohc@ietf.org; Fri, 20 Jun 2003 12:31:43 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19TOne-0006Sx-00 for rohc@ietf.org; Fri, 20 Jun 2003 12:31:43 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 17:31:41 +0100 Message-ID: From: "Price, Richard" To: "'Yousuf.Saifullah@nokia.com'" , Ghyslain.Pelletier@epl.ericsson.se Cc: rohc@ietf.org Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Fri, 20 Jun 2003 17:31:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > I am sorry if I was not clear earlier. Action on 8-bit CRC > (coverage complete IR-REPLICATE header) is taken after > decompressor fails 7-bit CRC (coverage original header) test. > If 7-bit CRC failed but 8-bit CRC passed, the decompressor > sends STATIC-NACK. It is sure now that the base context is > bad. If 7-bit CRC failed and 8-bit CRC also fails, then send > a NACK (R-mode) or ignore it and wait for subsequent > IR-RELICATE (U/O-mode). 8-bit CRC by itself is not considered > for decision. Please see my next comment also. Hi Yousuf, From reading Ghyslain's last email, I think that the current actions taken by the context replication draft are intended to be as follows: i) If the 8-bit CRC succeeds but the 7-bit CRC fails then send a STATIC-NACK. ii) If the 8-bit CRC fails (and hence the 7-bit CRC fails implicitly as the packet can't be decompressed) then ignore the packet and wait for the next IR-REPLICATE. This logic is fine for U/B-mode, and agrees with the logic you propose above. We might need different logic for different modes such as R-mode, but since we should focus only on U/B-mode at this stage, the above logic is ok. > > > 3) STATIC-NACK should be sent when one or more IR-REPLICATE fails > > > CRC-7 validation in the following case: > > > o no context has yet been established for this flow prior to the > > > packet(s) for which decompression failed. > > > I.e. case B: > > > No valid context has been established for that flow, and > > > decompression fails for one or more packets -> context never > > > established and is not suited to be a base context > > > (is a "bad context" for replication). > > > > > > Thus, case A is not triggering the sending of IRs, case B does. > > > > I agree with you for items 1) and 2). The case B is the one I > want to differ. The decompression failure doesn't always mean > "bad context". Let me explain, we have 7-bit CRC that covers > original header and 8-bit CRC that covers the IR-REPLICATE > packet header excluding payload (this is with the proposed > modification). A decompressor receives an initial > IR-REPLICATE. It decompresses the packet by using the > referred base context and the static/dynamic replication > chains provided in the IR-REPLICATE message. After > decompression it calculates 7-bit CRC and fails the 7-bit CRC > test. There are two sources of error, either the referred > base context is bad (case B-1) or the static/dynamic > replication chain provided in the IR-REPLICATE is bad (case > B-2). Let's say if the static/dynamic chain is bad, then > there is no justification for labeling this context as the > "bad context". Here the 8-bit CRC comes handy, if it passes > CRC check then the decompressor knows that the static/dynamic > chains are fine but the context is bad, and sends STATIC > NACK. The mechanism I proposed substracts out case B-2 from case B. I agree that if the CRC-8 fails then no STATIC-NACK should be sent (at least for U/B-mode). This isn't clear from the current draft, so let's clarify it in the next version... > CRC-7 by itself can't differentiate whether the error is in > the base context or the static/dynamic chains of > IR-REPLICATE. It is on the original header and can catch > error in the new replicated context, which is formed by the > aggregation of the base context and the received > static/dynamic chains. If we only use CRC-7 we'd be > discarding base contexts unnecessarily, and causing > transmission of IR for case B-2. Please see my previous comment. Yes. If CRC-8 fails then no STATIC-NACK should be sent. > For the feedback message, the request for another NACK is > mode specific and is for R mode. For U/O mode we don't need > to send explicit NACK. The confusion is that we try to do > profile independent CR discussion using a draft which is > profile dependent. I agree that it isn't currently clear whether the draft is trying to be applicable to all modes, or just to U/B-mode. My opinion is that we should stick to U/B-mode for now, as this is the mode used by ROHC-TCP. > I think we have introduced a new logic with context > replication for IR-REP then IR. It uses a base context that > has been acknowledged. It uses a unique packet format for > encoding. It may send STATIC-NACK. Note that the IR-REP state would be at the compressor rather than the decompressor, so its logic would dictate the actions upon *receiving* a STATIC-NACK rather than *sending* a STATIC-NACK. However, I tend to agree that the IR-REPLICATE packet introduces new logic which is different from the basic IR state. Therefore, it might be clearer to introduce a new IR-REP state into the state machine. > > > Furthermore, states a profile specific and the ROHC-CR is not. Your > > > drawing seems to have the state machine of ROHC-TCP in mind. > > > > This is not necessarily a problem, as we should be focusing on the U/B-mode > > state machine used in ROHC-TCP. It would be a mistake to make the draft too > > generic, as we would then need to redefine the state transition logic all > > over again for each specific profile. > > I have used ROHC-TCP diagram to draw it. My main point is > that should we add an "IR-REP" state or not? I have given my > comments on this above. I also think that keeping this > ROHC-CR document too generic so it won't have any substance > in it to depict a meaningful picture is not a good idea. Agreed! > The relation is this, we can't send STATIC-NACK in IR state > but we can send STATIC-NACK in IR-REP state. So by adding > IR-REP state, we are keeping whatever ROHC has decided about > IR state. Any new function or logic is executed from IR-REP state. I think that IR-REP state would be at the compressor, so the logic would dictate what to do when receiving a STATIC-NACK (namely transit to IR state), and conversely how to transit from IR state to IR-REP state (find a base context that has been successfully ACKed). > After reading the complete response from both of you, I think > it would be better if we don't keep ROHC-CR generic, and make > it specific for ROHC-TCP. How about changing it to > ROHC-TCP-CR? In this way we will be able to put enough > details and avoid unnecessary abstraction and confusion > resulting from it. We agree that we need to do CR for > ROHC-TCP first, so let's do this. IMO it is dangerous if we > write this ROHC-CR implicitly assuming TCP and then try to > mandate it as a generic CR solution for all the profiles. Would it be ok to make the draft specific to U/B-mode (which is used in ROHC-TCP)? This would be more generic than making the draft specific to ROHC-TCP, as we could then apply context replication to other ROHC profiles that also use U/B-mode. > The issue behind above disscussion is not about replicating a > "mode", but the issue is that are we going to document how > context replication would work in different modes? If yes, > then where? in ROHC-CR or individual profiles. I have already > suggested to have ROHC-TCP-CR and documenting in it whatever > mode is relevant to TCP. I think it's clear that we can't produce a context replication draft which is generic to all ROHC modes, as the draft would essentially end up saying nothing. If we keep the draft specific to U/B-mode for now then it will be much easier to define the compressor and decompressor logic for context replication. I still think it's worth keeping the context replication material separate from the genuinely TCP-specific material such as the packet formats. Even if context replication only applies to U/B-mode, it can still be reused for other ROHC profiles that also use this mode. > > In practice however, we need to weigh up the potential benefits of > > introducing a new feedback option relative to the extra effort required. > > In the case of ROHC-TCP, will transmission errors be sufficiently common > > to make this extra feedback option worthwhile? > > > > The transmission errors are common in lossy links. That's > where ROHC solutions will be used most. > > Let me also repeat that this feedback is not needed for > U/O-mode. It would be needed for R-mode. In U/O-mode the > compressor may continue to send IR-REPLICATE. I agree with the above. The suggestion to introduce a new feedback option might make sense for certain ROHC modes, but not for U/B-mode as used in ROHC-TCP. Let's focus on this mode for now... Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jun 20 13:33:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19425 for ; Fri, 20 Jun 2003 13:33:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KHX3c22028 for rohc-archive@odin.ietf.org; Fri, 20 Jun 2003 13:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPl1-0005jD-9q for rohc-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19357 for ; Fri, 20 Jun 2003 13:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPkz-00074E-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 13:33:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TPky-00074B-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 13:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPkz-0005h2-Uy; Fri, 20 Jun 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPkI-0005fq-If for rohc@optimus.ietf.org; Fri, 20 Jun 2003 13:32:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19272 for ; Fri, 20 Jun 2003 13:32:16 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPkG-00073e-00 for rohc@ietf.org; Fri, 20 Jun 2003 13:32:16 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19TPkF-00073a-00 for rohc@ietf.org; Fri, 20 Jun 2003 13:32:15 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KHWE118056 for ; Fri, 20 Jun 2003 12:32:14 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 20 Jun 2003 12:32:11 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 20 Jun 2003 12:31:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Fri, 20 Jun 2003 12:31:53 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139886D@daebe004.americas.nokia.com> Thread-Topic: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Thread-Index: AcM3SXzYEZiQtNKqRzW8giwuqEor2AAA2ONg To: , Cc: X-OriginalArrivalTime: 20 Jun 2003 17:31:54.0049 (UTC) FILETIME=[D74C5B10:01C33751] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA19425 Hi Richard, After reading your response, I think the only issue we need to resolve is the definition of 8-bit CRC. Please see my first comment below. BR, Yousuf > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Friday, June 20, 2003 11:32 AM > To: Saifullah Yousuf (NRC/Dallas); Ghyslain.Pelletier@epl.ericsson.se > Cc: rohc@ietf.org > Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and > some topics to be discussed) > > > > I am sorry if I was not clear earlier. Action on 8-bit CRC > > (coverage complete IR-REPLICATE header) is taken after > > decompressor fails 7-bit CRC (coverage original header) test. > > If 7-bit CRC failed but 8-bit CRC passed, the decompressor > > sends STATIC-NACK. It is sure now that the base context is > > bad. If 7-bit CRC failed and 8-bit CRC also fails, then send > > a NACK (R-mode) or ignore it and wait for subsequent > > IR-RELICATE (U/O-mode). 8-bit CRC by itself is not considered > > for decision. Please see my next comment also. > > Hi Yousuf, > > From reading Ghyslain's last email, I think that the current > actions taken > by the context replication draft are intended to be as follows: > > i) If the 8-bit CRC succeeds but the 7-bit CRC fails then send a > STATIC-NACK. > > ii) If the 8-bit CRC fails (and hence the 7-bit CRC fails > implicitly as > the packet can't be decompressed) then ignore the packet > and wait for > the next IR-REPLICATE. > > This logic is fine for U/B-mode, and agrees with the logic you propose > above. > We might need different logic for different modes such as > R-mode, but since > we should focus only on U/B-mode at this stage, the above logic is ok. > The main thing we need to agree on is the definition of 8-bit CRC. It should cover static/dynamic chain in the IR REPLICATE packet for finding out bad base context problem. With the 8-bit CRC definition as in the CR draft (excluding static/dynamic chains in IR-REPLICATE), point i) above will be sending STATIC-NACK even if the problem is in the received static/dynamic chains. > > > > 3) STATIC-NACK should be sent when one or more > IR-REPLICATE fails > > > > CRC-7 validation in the following case: > > > > o no context has yet been established for this flow > prior to the > > > > packet(s) for which decompression failed. > > > > I.e. case B: > > > > No valid context has been established for that flow, and > > > > decompression fails for one or more packets -> context never > > > > established and is not suited to be a base context > > > > (is a "bad context" for replication). > > > > > > > > Thus, case A is not triggering the sending of IRs, case B does. > > > > > > I agree with you for items 1) and 2). The case B is the one I > > want to differ. The decompression failure doesn't always mean > > "bad context". Let me explain, we have 7-bit CRC that covers > > original header and 8-bit CRC that covers the IR-REPLICATE > > packet header excluding payload (this is with the proposed > > modification). A decompressor receives an initial > > IR-REPLICATE. It decompresses the packet by using the > > referred base context and the static/dynamic replication > > chains provided in the IR-REPLICATE message. After > > decompression it calculates 7-bit CRC and fails the 7-bit CRC > > test. There are two sources of error, either the referred > > base context is bad (case B-1) or the static/dynamic > > replication chain provided in the IR-REPLICATE is bad (case > > B-2). Let's say if the static/dynamic chain is bad, then > > there is no justification for labeling this context as the > > "bad context". Here the 8-bit CRC comes handy, if it passes > > CRC check then the decompressor knows that the static/dynamic > > chains are fine but the context is bad, and sends STATIC > > NACK. The mechanism I proposed substracts out case B-2 from > case B. > > I agree that if the CRC-8 fails then no STATIC-NACK should be sent > (at least for U/B-mode). This isn't clear from the current draft, so > let's clarify it in the next version... > > > CRC-7 by itself can't differentiate whether the error is in > > the base context or the static/dynamic chains of > > IR-REPLICATE. It is on the original header and can catch > > error in the new replicated context, which is formed by the > > aggregation of the base context and the received > > static/dynamic chains. If we only use CRC-7 we'd be > > discarding base contexts unnecessarily, and causing > > transmission of IR for case B-2. Please see my previous comment. > > Yes. If CRC-8 fails then no STATIC-NACK should be sent. > > > For the feedback message, the request for another NACK is > > mode specific and is for R mode. For U/O mode we don't need > > to send explicit NACK. The confusion is that we try to do > > profile independent CR discussion using a draft which is > > profile dependent. > > I agree that it isn't currently clear whether the draft is trying to > be applicable to all modes, or just to U/B-mode. My opinion is that > we should stick to U/B-mode for now, as this is the mode used by > ROHC-TCP. > > > I think we have introduced a new logic with context > > replication for IR-REP then IR. It uses a base context that > > has been acknowledged. It uses a unique packet format for > > encoding. It may send STATIC-NACK. > > Note that the IR-REP state would be at the compressor rather than the > decompressor, so its logic would dictate the actions upon *receiving* > a STATIC-NACK rather than *sending* a STATIC-NACK. > > However, I tend to agree that the IR-REPLICATE packet introduces new > logic which is different from the basic IR state. Therefore, it might > be clearer to introduce a new IR-REP state into the state machine. > > > > > Furthermore, states a profile specific and the ROHC-CR > is not. Your > > > > drawing seems to have the state machine of ROHC-TCP in mind. > > > > > > This is not necessarily a problem, as we should be focusing on the > U/B-mode > > > state machine used in ROHC-TCP. It would be a mistake to > make the draft > too > > > generic, as we would then need to redefine the state > transition logic > all > > > over again for each specific profile. > > > > I have used ROHC-TCP diagram to draw it. My main point is > > that should we add an "IR-REP" state or not? I have given my > > comments on this above. I also think that keeping this > > ROHC-CR document too generic so it won't have any substance > > in it to depict a meaningful picture is not a good idea. > > Agreed! > > > The relation is this, we can't send STATIC-NACK in IR state > > but we can send STATIC-NACK in IR-REP state. So by adding > > IR-REP state, we are keeping whatever ROHC has decided about > > IR state. Any new function or logic is executed from IR-REP state. > > I think that IR-REP state would be at the compressor, so the logic > would dictate what to do when receiving a STATIC-NACK (namely > transit to IR state), and conversely how to transit from IR state > to IR-REP state (find a base context that has been > successfully ACKed). > I agree. > > After reading the complete response from both of you, I think > > it would be better if we don't keep ROHC-CR generic, and make > > it specific for ROHC-TCP. How about changing it to > > ROHC-TCP-CR? In this way we will be able to put enough > > details and avoid unnecessary abstraction and confusion > > resulting from it. We agree that we need to do CR for > > ROHC-TCP first, so let's do this. IMO it is dangerous if we > > write this ROHC-CR implicitly assuming TCP and then try to > > mandate it as a generic CR solution for all the profiles. > > Would it be ok to make the draft specific to U/B-mode (which is used > in ROHC-TCP)? This would be more generic than making the draft > specific to ROHC-TCP, as we could then apply context replication to > other ROHC profiles that also use U/B-mode. Agreed! We should also explicitly state that in the draft for clarification. > > > The issue behind above disscussion is not about replicating a > > "mode", but the issue is that are we going to document how > > context replication would work in different modes? If yes, > > then where? in ROHC-CR or individual profiles. I have already > > suggested to have ROHC-TCP-CR and documenting in it whatever > > mode is relevant to TCP. > > I think it's clear that we can't produce a context replication draft > which is generic to all ROHC modes, as the draft would essentially > end up saying nothing. If we keep the draft specific to U/B-mode for > now then it will be much easier to define the compressor and > decompressor logic for context replication. > > I still think it's worth keeping the context replication material > separate from the genuinely TCP-specific material such as the packet > formats. Even if context replication only applies to U/B-mode, it > can still be reused for other ROHC profiles that also use this mode. > > > > In practice however, we need to weigh up the potential benefits of > > > introducing a new feedback option relative to the extra > effort required. > > > In the case of ROHC-TCP, will transmission errors be > sufficiently common > > > to make this extra feedback option worthwhile? > > > > > > > The transmission errors are common in lossy links. That's > > where ROHC solutions will be used most. > > > > Let me also repeat that this feedback is not needed for > > U/O-mode. It would be needed for R-mode. In U/O-mode the > > compressor may continue to send IR-REPLICATE. > > I agree with the above. The suggestion to introduce a new feedback > option might make sense for certain ROHC modes, but not for U/B-mode > as used in ROHC-TCP. Let's focus on this mode for now... > > Regards, > > Richard > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > 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. > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jun 20 14:31:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24356 for ; Fri, 20 Jun 2003 14:31:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KIV3v08584 for rohc-archive@odin.ietf.org; Fri, 20 Jun 2003 14:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQf9-0002EN-Kw for rohc-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 14:31:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24271 for ; Fri, 20 Jun 2003 14:31:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQf6-00005x-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 14:31:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TQf6-00005r-00 for rohc-web-archive@ietf.org; Fri, 20 Jun 2003 14:31:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQf7-0002C9-RH; Fri, 20 Jun 2003 14:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQeO-00024g-DQ for rohc@optimus.ietf.org; Fri, 20 Jun 2003 14:30:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24018; Fri, 20 Jun 2003 14:30:13 -0400 (EDT) Message-Id: <200306201830.OAA24018@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 14:30:12 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-sip-00.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) Author(s) : Z. Liu, R. Price Filename : draft-ietf-rohc-sigcomp-sip-00.txt Pages : 8 Date : 2003-6-20 This document describes some specifics when Signaling Compression (SigComp) [RFC-3320] is applied to the Session Initiation Protocol (SIP) [RFC-3261]. Any SigComp implementation that is used for SIP compression must follow this document, in addition to [RFC-3320] and [RFC-3485]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-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-ietf-rohc-sigcomp-sip-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-ietf-rohc-sigcomp-sip-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: <2003-6-20140854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-sip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-sip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140854.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 23 06:07:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14733 for ; Mon, 23 Jun 2003 06:07:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NA7EC08270 for rohc-archive@odin.ietf.org; Mon, 23 Jun 2003 06:07:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UOEE-00029I-0H for rohc-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 06:07:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14719 for ; Mon, 23 Jun 2003 06:07:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UOEA-00010n-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 06:07:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UOE4-00010i-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 06:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UOE1-000230-2G; Mon, 23 Jun 2003 06:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UOD2-0001zE-Lb for rohc@optimus.ietf.org; Mon, 23 Jun 2003 06:06:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14661 for ; Mon, 23 Jun 2003 06:04:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UOBv-0000zF-00 for rohc@ietf.org; Mon, 23 Jun 2003 06:04:51 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19UOBl-0000yo-00 for rohc@ietf.org; Mon, 23 Jun 2003 06:04:41 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 11:03:51 +0100 Message-ID: From: "Price, Richard" To: "'Yousuf.Saifullah@nokia.com'" , Ghyslain.Pelletier@epl.ericsson.se Cc: rohc@ietf.org Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Mon, 23 Jun 2003 11:03:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > The main thing we need to agree on is the definition of 8-bit > CRC. It should cover static/dynamic chain in the IR REPLICATE > packet for finding out bad base context problem. With the > 8-bit CRC definition as in the CR draft (excluding > static/dynamic chains in IR-REPLICATE), point i) above will > be sending STATIC-NACK even if the problem is in the received > static/dynamic chains. Hi Yousuf, In the current ROHC-CR draft, the coverage of the 8-bit CRC is left as a choice for the individual profiles. Depending on the particular profile, the 8-bit CRC may or may not cover the static/dynamic chains in the IR-REPLICATE packet. However, I agree that if the CRC-8 *doesn't* cover the static/ dynamic chains, then there may be a potential conflict with the logic used at the decompressor. If the CRC-8 succeeds but the CRC-7 fails then the decompressor assumes that the problem lies in the context rather than in the IR-REPLICATE packet, and sends a STATIC-NACK to indicate that the context is bad. So the decompressor logic only works properly if the CRC-8 checks all of the fields in the IR-REPLICATE packet. I think that the best way to resolve this potential problem is just to specify that the 8-bit CRC must cover the entire IR-REPLICATE packet (except for the payload). Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 23 06:17:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14863 for ; Mon, 23 Jun 2003 06:17:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NAHUf09709 for rohc-archive@odin.ietf.org; Mon, 23 Jun 2003 06:17:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UOOA-0002WW-MN for rohc-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 06:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14848 for ; Mon, 23 Jun 2003 06:17:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UONj-00013t-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 06:17:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UONd-00013q-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 06:16:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UONg-0002Te-Oh; Mon, 23 Jun 2003 06:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UOMy-0002TN-B5 for rohc@optimus.ietf.org; Mon, 23 Jun 2003 06:16:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14843 for ; Mon, 23 Jun 2003 06:16:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UOMu-00013k-00 for rohc@ietf.org; Mon, 23 Jun 2003 06:16:12 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19UOMj-00013g-00 for rohc@ietf.org; Mon, 23 Jun 2003 06:16:01 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 11:15:42 +0100 Message-ID: From: "Surtees, Abigail" To: "'rohc@ietf.org'" Subject: RE: [rohc] Sigcomp Implementer's Guide Date: Mon, 23 Jun 2003 11:15:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi All, As I've not received any comments about the proposed additions to the SigComp Implementer's Guide (see below, posted 17/6) then I assume there are no objections. If anyone has any comments (positive or negative) please send them to the list by 12pm GMT tomorrow, after which time I will submit the draft. Cheers, Abbie > >Hi All, > >There have been some suggestions for additions to the >implementer's guide so here's the proposed text. Any comments >and other additions gratefully received. I'm planning to >resubmit the draft before the -0n deadline so would appreciate >comments before the end of this week please - this gives time >to make changes and agree them on the list before the deadline. > >Clarification that STATE-FREE is compartment specific: >2nd paragraph added to section 3.2: > >"The STATE-FREE instruction can only free state in the compartment > that corresponds to the message being decompressed. Attempting to > free state either from another compartment or that is locally > available has no effect." > >Summary of the outcome of discussion about dynamic DMS and SMS updates: > >"8. Dynamic Update of Resources > > Decompressor resources such as SMS and DMS can be >dynamically updated > at the compressor by use of the SMS and DMS bits in returned > parameters feedback (section 9.4.9). Changing resources dynamically > (apart from initial advertisements for each compartment) is not > expected to happen very often. > > If additional resources are advertised to a compressor then it is up > to the implementation at the compressor whether or not to >make use of > these resources. For example, if the decompressor advertises 8k SMS > but the compressor only has 4k SMS then the compressor may >choose not > to use the extra 4k (e.g. in order to monitor state saved at the > decompressor). In this case, there is no synchronisation problem. > The compressor must not use more than the most recently advertised > resources. Note that the compressor SMS is unofficial (enables > compressor to monitor decompressor state) and is separate from the > SMS advertised by the decompressor. > > Reducing the resources has potential synchronisation issues and so > should not be done unless absolutely necessary. If this is the case > then the memory should not be reclaimed until the remote >endpoint has > acknowledged the message sent with the advertisement. If state must > be deleted to accommodate a reduction in SMS then both endpoints > should delete it according to the state retention priority (section > 6.2). The compressor should use up to the amount of resources most > recently advertised." > >There was also a suggestion about clarification that state too >large for the available SMS in shared mode should be truncated >(and the hash computed appropriately). >IMHO this is no different from any other state that is too >large and is clear in RFC 3320. Does anyone think this is a >useful clarification to include? > >Best regards, > >Abbie > >Abbie Surtees >Engineer >Internet Applications and Mobility >Roke Manor Research Ltd >Tel: +44 (0) 1794 833131 > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 23 09:43:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20187 for ; Mon, 23 Jun 2003 09:43:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NDh8P04428 for rohc-archive@odin.ietf.org; Mon, 23 Jun 2003 09:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URbA-00019L-4J for rohc-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 09:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20178 for ; Mon, 23 Jun 2003 09:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URb8-0002Hs-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 09:43:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URb2-0002Hp-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 09:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URb3-00018q-0B; Mon, 23 Jun 2003 09:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URaa-00018e-14 for rohc@optimus.ietf.org; Mon, 23 Jun 2003 09:42:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20168 for ; Mon, 23 Jun 2003 09:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URaY-0002HV-00 for rohc@ietf.org; Mon, 23 Jun 2003 09:42:30 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19URaM-0002HR-00 for rohc@ietf.org; Mon, 23 Jun 2003 09:42:18 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5NDg0w2016725; Mon, 23 Jun 2003 15:42:00 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGM1SZN; Mon, 23 Jun 2003 15:42:00 +0200 Received: by lms001.lu.erisoft.se id PAA25502; Mon, 23 Jun 2003 15:41:51 +0200 (MET DST) Message-ID: <3EF703B2.3195FFE1@epl.ericsson.se> Date: Mon, 23 Jun 2003 15:42:10 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" , "'Yousuf.Saifullah@nokia.com'" , rohc@ietf.org Subject: Re: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id PAA25502 Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Richard and Yousuf, Thanks for your review and comments. I think it's best at this time to extract some points of that discussion rather than commenting on specifics. I'd thus like to summarize my understanding of the result of that thread regarding ROHC-CR: o ROHC-CR is a generic ROHC mechanism: CR is profile independent, it is not specific to ROHC-TCP but the draft will make assumptions coherent with the ROHC-TCP profile - while ensuring that as little work as possible would be necessary for other profiles to implement CR. o Profile-specific part of ROHC-CR: Profile-specific part of ROHC-CR will be specified in the document where support for ROHC-CR is added, such as in a draft describing a new ROHC profile (e.g. the ROHC-TCP draft) and potentially updated revisions of existing profiles. Hopefully, this will be as little work as possible. o ROHC-CR and modes: ROHC-CR should not attempt to be applicable to arbitrary modes, and we should not spend significant effort on covering the various behaviors for all possible modes. The draft will instead assume a U/B-mode type of operation. This is how the draft is currently written, but the approach will be further clarified in the next version. This is motivated by the ROHC-TCP profile being the main motivation behind ROHC-CR. o 8-bit CRC in IR-REPLICATE: The coverage will be made profile-independent. The CRC will cover the entire IR-REPLICATE packet, except the payload. This will be changed in the next version.=20 o Actions upon CRC-8 failure The draft currently relies on text in rfc-3095 for this. It has been suggested that this may create some unclarity. This will be adjusted in the next version with text similar to rfc-3095 section 5.2.6 (item #10). o New state for IR-REPLICATE Richard summarized this potential new state as follow: "I think that IR-REP state would be at the compressor, so the logic would dictate what to do when receiving a STATIC-NACK (namely transit to IR state), and conversely how to transit from IR state to IR-REP state (find a base context that has been successfully ACKed)." The first part of the above sentence basically corresponds to section 3.2.2.1/3.2.2.2 and the second part corresponds to section 3.2.1 of the ROHC-CR draft. I find motivations to add an additional state for CR somewhat thin, also in relation to the limited amount of logic attached to it and because ROHC-CR does not define a complete state machine. This issue in my opinion is only a matter of how to document logic to support the IR-REPLICATE, it is not about the logic itself (for which we seem to have agreement). I'd prefer instead that we make an attempt in ensuring that the text for both the compressor and decompressor logic is clear when using the IR-REPLICATE. It seems that the part related to the compressor logic is the bit that could be better. =20 This should be clearer in the next version. If this is not possible, then we might want to consider document this logic using a more pedagogical representation, like adding such a new state. But right now I don't see any compelling need/reason for this. Hopefully we can agree on this for now.=20 o Feedback with ROHC-CR: It seems that current feedback options from rfc-3095 are sufficient for ROHC-CR and with respect to the U/B-mode assumption. No new options are needed with this assumption. Let me know if I have missed something. Thanks again. /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 23 12:21:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27306 for ; Mon, 23 Jun 2003 12:21:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NGL8c01747 for rohc-archive@odin.ietf.org; Mon, 23 Jun 2003 12:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UU44-0000S6-Jp for rohc-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 12:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27292 for ; Mon, 23 Jun 2003 12:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UU43-0003WP-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 12:21:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UU3x-0003WM-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 12:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UU3x-0000QM-FC; Mon, 23 Jun 2003 12:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UU35-0000PP-Hf for rohc@optimus.ietf.org; Mon, 23 Jun 2003 12:20:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27267 for ; Mon, 23 Jun 2003 12:20:04 -0400 (EDT) From: vkatyal@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UU34-0003Vg-00 for rohc@ietf.org; Mon, 23 Jun 2003 12:20:06 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19UU2r-0003UN-00 for rohc@ietf.org; Mon, 23 Jun 2003 12:19:54 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5NGEgL19580 for ; Mon, 23 Jun 2003 21:44:42 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5NGEfO19573 for ; Mon, 23 Jun 2003 21:44:41 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h5NGIDh26175 for ; Mon, 23 Jun 2003 21:48:13 +0530 (IST) To: rohc@ietf.org Date: Mon, 23 Jun 2003 21:43:03 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 23/06/2003 09:42:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] Query on List compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Dear Experts, When at the compressor side List compression is applied in case of say IP/AH/UDP/RTP, then at the decompressor side, how to determine the first extension type in the IP (IR) "Generic extension header list". Another question is considering the scenario where we have multiple IP headers - eg. IP/IP/IP/AH/UDP/RTP then how these headers will be organised/arranged in compressed header ? regards, Vishal "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 23 12:43:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28195 for ; Mon, 23 Jun 2003 12:43:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NGh7c06893 for rohc-archive@odin.ietf.org; Mon, 23 Jun 2003 12:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UUPL-0001n6-Jq for rohc-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 12:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28188 for ; Mon, 23 Jun 2003 12:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UUPJ-0003jS-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 12:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UUPE-0003jP-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 12:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UUPE-0001kZ-R3; Mon, 23 Jun 2003 12:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UUPA-0001kL-AM for rohc@optimus.ietf.org; Mon, 23 Jun 2003 12:42:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28177 for ; Mon, 23 Jun 2003 12:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UUOt-0003jC-00 for rohc@ietf.org; Mon, 23 Jun 2003 12:42:39 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19UUOh-0003io-00 for rohc@ietf.org; Mon, 23 Jun 2003 12:42:28 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id C1A6A8A77E; Tue, 24 Jun 2003 02:11:32 +0930 (CST) Date: Tue, 24 Jun 2003 02:11:32 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030624021132.A8707@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] suggestion for future RTP profile Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , I guess most people have no interest in changes to the RTP compression any more, but anyway here is an idea for improved compression in the future. While implementing profile 0x0001, I have found that it would be much better to have two different numbers instead of TS-stride. The values would be: TS-scale = the scale to apply to the TS before applying LSB encoding TS-slope = the rate of change of TS with respect to SN when the TS field is not sent at all. At present, these are always the same number. To give an example of the problem, I have been watching some audio/RTP traffic (GSM 06.10) which has usually 4 audio frames per packet. Therefore normally I have frame time = 160 cycles at 8 kHz = 20 mSec packet time = 640 cycles at 8 kHz = 80 mSec. However, the code often skips a frame and makes the TS value change by 480, 800 or 960 cycles. Then the value of TS-stride = 640 is invalid. In fact, because of the W-LSB algorithm, I must send the absolute 32-bit TS value for several packets after this codec clock skip. This causes a noticeable degradation of ROHC compression performance. Now suppose I use TS-stride = 160 instead. Then I can use the 4-bit or 6-bit compressed, scaled TS value for just the one strange packet. But if I use TS-stride = 160, then it is wrong for the implicit 0-bit TS field in the UO-0 packet, for example, because 640 does not equal 160. Therefore I can never use UO-0 packets in this case. So what I really need is TS-stride = 640 for the default TS step if the TS field is not sent explicitly, e.g. in UO-0. But I want TS-stride = 160 for the scale when I send LSB encoding. The solution to this is to have two different fields: TS-scale and TS-slope. Then TS-slope is used for 0-bit TS encoding, and TS-scale is used for k-bit W-LSB encoding for k > 0. Then I would put: TS-scale = 160 TS-slope = 640 It would be very easy to include this idea in the packet format for IR packets for profile 0x0001 because there are 3 reserved bits in the same octet as the TIS and TSS fields. (RFC 3095, 5.7.7.6, page 102.) The extension 3 format is probably a bit more difficult. This idea could be incorporated into the next version of 0x0001 !! Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington website: http://www.topology.org/ city: Adelaide, South Australia coords: 138.59 E, 34.88 S timezone: UTC+0930 http://www.topology.org/site/timezone.html pgp-key: http://www.topology.org/ak/key_ak2.asc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 23 13:52:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01051 for ; Mon, 23 Jun 2003 13:52:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NHq7s18717 for rohc-archive@odin.ietf.org; Mon, 23 Jun 2003 13:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVU7-0004ro-BG for rohc-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 13:52:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01017 for ; Mon, 23 Jun 2003 13:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVU5-0004HM-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 13:52:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UVTz-0004HJ-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 13:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVU0-0004oJ-Tl; Mon, 23 Jun 2003 13:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVTF-0004nO-0E for rohc@optimus.ietf.org; Mon, 23 Jun 2003 13:51:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00979 for ; Mon, 23 Jun 2003 13:51:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVTC-0004Gl-00 for rohc@ietf.org; Mon, 23 Jun 2003 13:51:10 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19UVT1-0004GG-00 for rohc@ietf.org; Mon, 23 Jun 2003 13:50:59 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 18:50:07 +0100 Message-ID: From: "Price, Richard" To: "'Ghyslain Pelletier'" , "'Yousuf.Saifullah@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Mon, 23 Jun 2003 18:50:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA00981 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Richard and Yousuf, >=20 > Thanks for your review and comments. I think it's best at this time to > extract some points of that discussion rather than commenting on > specifics. I'd thus like to summarize my understanding of the result of > that thread regarding ROHC-CR: >=20 > o ROHC-CR is a generic ROHC mechanism: > CR is profile independent, it is not specific to ROHC-TCP but the > draft will make assumptions coherent with the ROHC-TCP profile - > while ensuring that as little work as possible would be necessary > for other profiles to implement CR. This seems like a sensible way to proceed. We should keep the ROHC-CR mechanism applicable to more profiles than just ROHC-TCP, but not at the expense of significant extra work (since ROHC-TCP is still the primary motivation for context replication). Same approach as we're taking for the formal notation. > o Profile-specific part of ROHC-CR: > Profile-specific part of ROHC-CR will be specified in the document > where support for ROHC-CR is added, such as in a draft describing > a new ROHC profile (e.g. the ROHC-TCP draft) and potentially > updated revisions of existing profiles. Hopefully, this will be > as little work as possible. Yes. With any luck, the only profile-specific part of ROHC-CR will be the IR-REPLICATE packet formats. > o ROHC-CR and modes: > ROHC-CR should not attempt to be applicable to arbitrary modes, > and we should not spend significant effort on covering the various > behaviors for all possible modes. The draft will instead assume a > U/B-mode type of operation. This is how the draft is currently > written, but the approach will be further clarified in the next > version. This is motivated by the ROHC-TCP profile being the > main motivation behind ROHC-CR. Yes. > o 8-bit CRC in IR-REPLICATE: > The coverage will be made profile-independent. The CRC will cover > the entire IR-REPLICATE packet, except the payload. This will be > changed in the next version.=20 Agreed. > o Actions upon CRC-8 failure > The draft currently relies on text in rfc-3095 for this. It has > been suggested that this may create some unclarity. This will be > adjusted in the next version with text similar to rfc-3095 > section 5.2.6 (item #10). We also need to specify that if the CRC-8 fails then a STATIC-NACK is not sent (Section 5.2.6 of RFC 3095 does not mandate whether to do this or not, and in fact O-mode *does* send a STATIC-NACK if the CRC-8 fails). > o New state for IR-REPLICATE >=20 > Richard summarized this potential new state as follow: >=20 > "I think that IR-REP state would be at the compressor, so the > logic would dictate what to do when receiving a STATIC-NACK > (namely transit to IR state), and conversely how to transit from > IR state to IR-REP state (find a base context that has been > successfully ACKed)." >=20 > The first part of the above sentence basically corresponds to > section 3.2.2.1/3.2.2.2 and the second part corresponds to section > 3.2.1 of the ROHC-CR draft. >=20 > I find motivations to add an additional state for CR somewhat thin, > also in relation to the limited amount of logic attached to it In general, I believe that the purpose of the compressor state machine is to provide information needed by a context to decide which packet format to use when compressing a header. Different states allow a different range of packet formats to be used. Transitions between the states occur as a result of feedback from the decompressor, or due to compressor-local mechanisms (e.g. optimistic approach, timeouts etc.). Context replication provides an additional factor to take into account when choosing a suitable packet format - namely whether a base context is available or not. This factor works in exactly the same way as the existing states in the compressor state machine. It determines the range of packet formats that can be used, and it is changed as a result of feedback from the decompressor or due to compressor-local mechanisms (i.e. discovering that a suitable base context is available). It therefore makes sense to introduce a new "REPLICATE" state into the compressor state machine. The only alternative would be to introduce context replication as a "sub-state" to one of the existing states, e.g. dividing the IR state into an IR-ORDINARY and an IR-REP sub-state. However, to me this is much more confusing. It's not at all clear that context replication is a particular instance of the IR state - on the contrary, I think that it has more in common with the CO state than the IR state. In particular, both IR-REP and CO states allow packet formats to use window-based encoding methods, which is explicitly banned in the RFC 3095 definition of the IR state. > and because ROHC-CR does not define a complete state machine. However, ROHC-TCP itself will certainly have to define a state machine for the compressor, and this state machine will need to take context replication into account. I don't see any advantage in creating a basic ROHC-TCP state machine and then trying to add context replication as an extra feature on top. Why not just build support for context replication into the state machine from the beginning? > This issue in my opinion is only a matter of how to document logic > to support the IR-REPLICATE, it is not about the logic itself (for > which we seem to have agreement). There's more to a state machine than just the state transition logic. We also need to define the range of packet formats that can be used for a given state, and any context entries needed to retain the state of the state machine between successive packets. For context replication we're introducing two new pieces of information that must be stored in the compressor context: the identifier for the bas= e context, and some kind of indicator that the base context is valid. I think it makes sense for this indicator to be stored as an extra state for the state machine (i.e. as an extra value for the context entry C_STATE), which says that the base context is valid and can be used. > I'd prefer instead that we make an attempt in ensuring that the text > for both the compressor and decompressor logic is clear when using > the IR-REPLICATE. It seems that the part related to the compressor > logic is the bit that could be better. I think that the text will be much less confusing if we treat IR-REP as a new state, rather than trying to shoehorn it into the existing IR state= , where it doesn't really fit. > This should be clearer in the next version. If this is not possible, > then we might want to consider document this logic using a more > pedagogical representation, like adding such a new state. But right > now I don't see any compelling need/reason for this. Hopefully we > can agree on this for now.=20 I don't see how we can avoid adding a new state for context replication, except by making it a sub-state of the existing IR state or the CO state. I think that this latter approach would be much more confusing... Moreover, are there any real advantages in *not* introducing a new state for context replication? > o Feedback with ROHC-CR: > It seems that current feedback options from rfc-3095 are sufficient > for ROHC-CR and with respect to the U/B-mode assumption. No new > options are needed with this assumption. Agreed. > Let me know if I have missed something. Thanks again. >=20 > /Ghyslain >=20 > Ghyslain Pelletier, Dipl. Ing. > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit >=20 > Ericsson AB, Laboratoriegr=E4nd 11 > Box 920, S-97128 Lule=E5, SWEDEN > Phone : +46 (0) 920 20 24 32=20 > Mobile: +46 (0) 706 09 27 73 > Ghyslain.Pelletier@epl.ericsson.se > http://www.ericsson.com >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 23 17:55:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11725 for ; Mon, 23 Jun 2003 17:55:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NLt7V23863 for rohc-archive@odin.ietf.org; Mon, 23 Jun 2003 17:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZHH-0006Co-Io for rohc-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 17:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11711 for ; Mon, 23 Jun 2003 17:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZHE-00060y-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 17:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UZH9-00060v-00 for rohc-web-archive@ietf.org; Mon, 23 Jun 2003 17:54:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZHA-00069s-Vo; Mon, 23 Jun 2003 17:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZGG-00068R-LT for rohc@optimus.ietf.org; Mon, 23 Jun 2003 17:54:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11702 for ; Mon, 23 Jun 2003 17:54:00 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZGE-00060Y-00 for rohc@ietf.org; Mon, 23 Jun 2003 17:54:02 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19UZG3-00060T-00 for rohc@ietf.org; Mon, 23 Jun 2003 17:53:51 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NLreG20849 for ; Mon, 23 Jun 2003 16:53:40 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 23 Jun 2003 16:53:39 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 23 Jun 2003 14:52:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Mon, 23 Jun 2003 16:52:57 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398872@daebe004.americas.nokia.com> Thread-Topic: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Thread-Index: AcM5r+y798kMAtbORaiBMPcU05wAiAAHQW2g To: , , X-OriginalArrivalTime: 23 Jun 2003 21:52:58.0692 (UTC) FILETIME=[CF647040:01C339D1] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ghyslain and Richard, Please see my response below. Thanks, Yousuf > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Monday, June 23, 2003 12:50 PM > To: 'Ghyslain Pelletier'; Saifullah Yousuf (NRC/Dallas); rohc@ietf.org > Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and > some topics to be discussed) >=20 >=20 > > Richard and Yousuf, > >=20 > > Thanks for your review and comments. I think it's best at=20 > this time to > > extract some points of that discussion rather than commenting on > > specifics. I'd thus like to summarize my understanding of=20 > the result of > > that thread regarding ROHC-CR: > >=20 > > o ROHC-CR is a generic ROHC mechanism: > > CR is profile independent, it is not specific to ROHC-TCP but the > > draft will make assumptions coherent with the ROHC-TCP profile - > > while ensuring that as little work as possible would be necessary > > for other profiles to implement CR. >=20 > This seems like a sensible way to proceed. We should keep the ROHC-CR > mechanism applicable to more profiles than just ROHC-TCP, but not at > the expense of significant extra work (since ROHC-TCP is still the > primary motivation for context replication). Same approach as we're > taking for the formal notation. >=20 Agreed, but all the assumptions need to be documented in the draft. This = would help in case there is a need for extending the protocol to the = other profiles.=20 > > o Profile-specific part of ROHC-CR: > > Profile-specific part of ROHC-CR will be specified in the document > > where support for ROHC-CR is added, such as in a draft describing > > a new ROHC profile (e.g. the ROHC-TCP draft) and potentially > > updated revisions of existing profiles. Hopefully, this will be > > as little work as possible. >=20 > Yes. With any luck, the only profile-specific part of ROHC-CR will be > the IR-REPLICATE packet formats. >=20 Agreed. > > o ROHC-CR and modes: > > ROHC-CR should not attempt to be applicable to arbitrary modes, > > and we should not spend significant effort on covering the various > > behaviors for all possible modes. The draft will instead assume a > > U/B-mode type of operation. This is how the draft is currently > > written, but the approach will be further clarified in the next > > version. This is motivated by the ROHC-TCP profile being the > > main motivation behind ROHC-CR. >=20 > Yes. Agreed. >=20 > > o 8-bit CRC in IR-REPLICATE: > > The coverage will be made profile-independent. The CRC will cover > > the entire IR-REPLICATE packet, except the payload. This will be > > changed in the next version.=20 >=20 > Agreed. Agreed. >=20 > > o Actions upon CRC-8 failure > > The draft currently relies on text in rfc-3095 for this. It has > > been suggested that this may create some unclarity. This will be > > adjusted in the next version with text similar to rfc-3095 > > section 5.2.6 (item #10). >=20 > We also need to specify that if the CRC-8 fails then a STATIC-NACK > is not sent (Section 5.2.6 of RFC 3095 does not mandate whether to > do this or not, and in fact O-mode *does* send a STATIC-NACK if the > CRC-8 fails). I agree with Richard's comment. >=20 > > o New state for IR-REPLICATE > >=20 > > Richard summarized this potential new state as follow: > >=20 > > "I think that IR-REP state would be at the compressor, so the > > logic would dictate what to do when receiving a STATIC-NACK > > (namely transit to IR state), and conversely how to transit from > > IR state to IR-REP state (find a base context that has been > > successfully ACKed)." > >=20 > > The first part of the above sentence basically corresponds to > > section 3.2.2.1/3.2.2.2 and the second part corresponds to section > > 3.2.1 of the ROHC-CR draft. > >=20 > > I find motivations to add an additional state for CR=20 > somewhat thin, > > also in relation to the limited amount of logic attached to it >=20 > In general, I believe that the purpose of the compressor state machine > is to provide information needed by a context to decide which packet > format to use when compressing a header. Different states allow a > different range of packet formats to be used. Transitions between the > states occur as a result of feedback from the decompressor, or due to > compressor-local mechanisms (e.g. optimistic approach, timeouts etc.). >=20 > Context replication provides an additional factor to take into account > when choosing a suitable packet format - namely whether a base context > is available or not. This factor works in exactly the same way as the > existing states in the compressor state machine. It determines the > range of packet formats that can be used, and it is changed as a > result of feedback from the decompressor or due to compressor-local > mechanisms (i.e. discovering that a suitable base context is=20 > available). >=20 > It therefore makes sense to introduce a new "REPLICATE" state into the > compressor state machine. The only alternative would be to introduce > context replication as a "sub-state" to one of the existing states, > e.g. dividing the IR state into an IR-ORDINARY and an IR-REP=20 > sub-state. > However, to me this is much more confusing. It's not at all clear that > context replication is a particular instance of the IR state - on the > contrary, I think that it has more in common with the CO=20 > state than the > IR state. In particular, both IR-REP and CO states allow=20 > packet formats > to use window-based encoding methods, which is explicitly=20 > banned in the > RFC 3095 definition of the IR state. >=20 > > and because ROHC-CR does not define a complete state machine. >=20 > However, ROHC-TCP itself will certainly have to define a state machine > for the compressor, and this state machine will need to take context > replication into account. I don't see any advantage in=20 > creating a basic > ROHC-TCP state machine and then trying to add context=20 > replication as an > extra feature on top. Why not just build support for context=20 > replication > into the state machine from the beginning? >=20 > > This issue in my opinion is only a matter of how to document logic > > to support the IR-REPLICATE, it is not about the logic itself (for > > which we seem to have agreement). >=20 > There's more to a state machine than just the state=20 > transition logic. We > also need to define the range of packet formats that can be used for a > given state, and any context entries needed to retain the state of the > state machine between successive packets. >=20 > For context replication we're introducing two new pieces of=20 > information > that must be stored in the compressor context: the identifier=20 > for the base > context, and some kind of indicator that the base context is valid. I > think it makes sense for this indicator to be stored as an extra state > for the state machine (i.e. as an extra value for the context entry > C_STATE), which says that the base context is valid and can be used. >=20 > > I'd prefer instead that we make an attempt in ensuring=20 > that the text > > for both the compressor and decompressor logic is clear when using > > the IR-REPLICATE. It seems that the part related to the compressor > > logic is the bit that could be better. >=20 > I think that the text will be much less confusing if we treat=20 > IR-REP as > a new state, rather than trying to shoehorn it into the=20 > existing IR state, > where it doesn't really fit. >=20 > > This should be clearer in the next version. If this is=20 > not possible, > > then we might want to consider document this logic using a more > > pedagogical representation, like adding such a new state.=20 > But right > > now I don't see any compelling need/reason for this. Hopefully we > > can agree on this for now.=20 >=20 > I don't see how we can avoid adding a new state for context=20 > replication, > except by making it a sub-state of the existing IR state or=20 > the CO state. > I think that this latter approach would be much more confusing... >=20 > Moreover, are there any real advantages in *not* introducing=20 > a new state > for context replication? On this "IR-REP" discussion, I support Richard's comments. I have given = my reasons and I don't have anything else to add. =20 >=20 > > o Feedback with ROHC-CR: > > It seems that current feedback options from rfc-3095 are=20 > sufficient > > for ROHC-CR and with respect to the U/B-mode assumption. No new > > options are needed with this assumption. >=20 > Agreed. Agreed. =20 >=20 > > Let me know if I have missed something. Thanks again. > >=20 > > /Ghyslain > >=20 > > Ghyslain Pelletier, Dipl. Ing. > > Wireless IP Optimizations > > AWARE - Advanced Wireless Algorithm Research > > Ericsson Research, Corporate Unit > >=20 > > Ericsson AB, Laboratoriegr=E4nd 11 > > Box 920, S-97128 Lule=E5, SWEDEN > > Phone : +46 (0) 920 20 24 32=20 > > Mobile: +46 (0) 706 09 27 73 > > Ghyslain.Pelletier@epl.ericsson.se > > http://www.ericsson.com > >=20 >=20 > -- > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, > Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to > Roke Manor Research Ltd and must not be passed to any third=20 > party without > permission. This communication is for information only and=20 > shall not create or > change any contractual relationship. >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jun 25 12:27:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20138 for ; Wed, 25 Jun 2003 12:27:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGRDl09762 for rohc-archive@odin.ietf.org; Wed, 25 Jun 2003 12:27:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VD72-0002XN-UE for rohc-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:27:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20122 for ; Wed, 25 Jun 2003 12:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VD72-0005BU-00 for rohc-web-archive@ietf.org; Wed, 25 Jun 2003 12:27:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VD6x-0005BM-00 for rohc-web-archive@ietf.org; Wed, 25 Jun 2003 12:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VD6q-0002TG-F9; Wed, 25 Jun 2003 12:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VD6T-0002S4-3M for rohc@optimus.ietf.org; Wed, 25 Jun 2003 12:26:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20074 for ; Wed, 25 Jun 2003 12:26:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VD6S-0005Ah-00 for rohc@ietf.org; Wed, 25 Jun 2003 12:26:36 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19VD6H-00059F-00 for rohc@ietf.org; Wed, 25 Jun 2003 12:26:25 -0400 Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h5PGNWAO029156; Wed, 25 Jun 2003 18:23:32 +0200 (MEST) Date: Wed, 25 Jun 2003 18:23:26 +0200 Subject: Re: [rohc] UDVM working code Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , rohc@ietf.org To: "Jagan S" From: Carsten Bormann In-Reply-To: Message-Id: <592F39A8-A729-11D7-92E6-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I currently working on implementation of SigComp in Linux. > Can anybody provide me the links, where can I get the source > code/library > for UDVM. ( am I right in asking this question.?....plz correct me, if > I am > wrong & also help me in using correct UDVM for the experiment). Jagan, I never got around to updating it for the RFC version of SigComp, but a working proof-of-concept for the draft -05 version of SigComp is under http://www.dmn.tzi.org/ietf/rohc/udvm/ -- this version is obsolete, but the code should be easily salvageable. It is in Perl, but moving it to C/C++ would be a SMOP (small matter of programming)... Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jun 26 01:01:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26053 for ; Thu, 26 Jun 2003 01:01:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q517h21875 for rohc-archive@odin.ietf.org; Thu, 26 Jun 2003 01:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VOsd-0005gk-8E for rohc-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 01:01:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26026 for ; Thu, 26 Jun 2003 01:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VOsa-0005Xv-00 for rohc-web-archive@ietf.org; Thu, 26 Jun 2003 01:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VOsU-0005Xs-00 for rohc-web-archive@ietf.org; Thu, 26 Jun 2003 01:00:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VOsW-0005gO-Hf; Thu, 26 Jun 2003 01:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VOrv-0005fZ-RE for rohc@optimus.ietf.org; Thu, 26 Jun 2003 01:00:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26002 for ; Thu, 26 Jun 2003 01:00:19 -0400 (EDT) From: vkatyal@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VOrt-0005Xh-00 for rohc@ietf.org; Thu, 26 Jun 2003 01:00:21 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19VOrh-0005XL-00 for rohc@ietf.org; Thu, 26 Jun 2003 01:00:09 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5Q4uFF14156 for ; Thu, 26 Jun 2003 10:26:15 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h5Q4uDO14141 for ; Thu, 26 Jun 2003 10:26:13 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h5Q4xji03465 for ; Thu, 26 Jun 2003 10:29:45 +0530 (IST) To: rohc@ietf.org Date: Thu, 26 Jun 2003 10:24:32 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 26/06/2003 10:23:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] List Compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Dear Rohc Experts, Kindly provide some clarifications on the points given below. Considering a scenario where we have an IP stream - IP/AH/UDP/RTP. Here, after receiving the first packet compressor determines that list compression is to be used because of the extension header AH is present. Compressor fills the "Generic extension header list" with AH header and send the compressed header to the decompressor. At the decompressor side while analysing the packet received - In static list the next header field in IP header will point to UDP , And therefore there is no way to determine which extension header is present in "Generic extension header list". Another question is considering the scenario where we have multiple IP headers - eg. IP/IP/IP/AH/UDP/RTP then how these headers will be organised/arranged in compressed header ? One way could be we can use the "Generic extension header list" to do so OR is there some other way to do so ?? For example in case of IR it could be - static chain - (First IP header static info ) + (Second IP header static info ) + UDP static info + RTP static info dynamic chain - (First IP header dynamic info ) + (Second dynamic IP header dynamic info ) + UDP dynamic info + RTP dynamic info regards, Vishal Vishal Katyal 06/23/2003 05:13 PM To: rohc@ietf.org cc: Subject: Query on List compression Dear Experts, When at the compressor side List compression is applied in case of say IP/AH/UDP/RTP, then at the decompressor side, how to determine the first extension type in the IP (IR) "Generic extension header list". Another question is considering the scenario where we have multiple IP headers - eg. IP/IP/IP/AH/UDP/RTP then how these headers will be organised/arranged in compressed header ? regards, Vishal _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jun 26 06:55:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15051 for ; Thu, 26 Jun 2003 06:55:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QAt8n09430 for rohc-archive@odin.ietf.org; Thu, 26 Jun 2003 06:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUPE-0002S1-9h for rohc-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 06:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15043 for ; Thu, 26 Jun 2003 06:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUPA-0007Ob-00 for rohc-web-archive@ietf.org; Thu, 26 Jun 2003 06:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VUP4-0007OY-00 for rohc-web-archive@ietf.org; Thu, 26 Jun 2003 06:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUP7-0002Re-4d; Thu, 26 Jun 2003 06:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUOv-0002NO-6g for rohc@optimus.ietf.org; Thu, 26 Jun 2003 06:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15038 for ; Thu, 26 Jun 2003 06:54:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUOq-0007OU-00 for rohc@ietf.org; Thu, 26 Jun 2003 06:54:44 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19VUOg-0007OM-00 for rohc@ietf.org; Thu, 26 Jun 2003 06:54:34 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5QAt0cv000692; Thu, 26 Jun 2003 12:55:00 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 26 Jun 2003 12:52:38 +0200 Message-ID: From: "Jan Christoffersson (EAB)" To: "'zhigang.c.liu@nokia.com'" , richard.price@roke.co.uk, rohc@ietf.org Date: Thu, 26 Jun 2003 12:53:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [rohc] Minimum DMS Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I have a comment on the recently released draft draft-ietf-rohc-sigcomp-sip-00.txt. I think having a minimal DMS of 8K is too much. I think that 4K must be enough for the great majority of situations. Since it is also the case that any endpoint may offer more than the minimum parameter value I think we should definitely not make 8K minimum for SIP/SigComp. Best Regards Jan P.S. I'll be out of office for a while so I will probably not answer any comments to this mail until I'm back. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jun 26 13:10:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09733 for ; Thu, 26 Jun 2003 13:10:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QHACx32026 for rohc-archive@odin.ietf.org; Thu, 26 Jun 2003 13:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VaGC-0008KT-QG for rohc-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 13:10:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09692 for ; Thu, 26 Jun 2003 13:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VaGA-0003yO-00 for rohc-web-archive@ietf.org; Thu, 26 Jun 2003 13:10:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VaG5-0003yH-00 for rohc-web-archive@ietf.org; Thu, 26 Jun 2003 13:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VaG0-0008Ij-QT; Thu, 26 Jun 2003 13:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VaFK-0008FT-KA for rohc@optimus.ietf.org; Thu, 26 Jun 2003 13:09:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09654 for ; Thu, 26 Jun 2003 13:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VaF3-0003xm-00 for rohc@ietf.org; Thu, 26 Jun 2003 13:09:01 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19VaEs-0003xI-00 for rohc@ietf.org; Thu, 26 Jun 2003 13:08:51 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 098EA8A76C; Fri, 27 Jun 2003 02:37:44 +0930 (CST) Date: Fri, 27 Jun 2003 02:37:44 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030627023744.A5357@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] RFC 3095: TS encoding/decoding in extension 3, profile 0x0001 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This is a question which is relevant to interoperability, but which does not seem to be answered in RFC 3095 or the ROCH implementer's guide, version 3. Maybe this question should be answered in the next version of the ROHC implementer's guide. RFC 3095, 5.7.5, p.85 says this about coding of TS in extension 3: ----------------------------------------------------- TS: Variable number of bits of TS, encoded according to section 4.5.6. See the beginning of section 5.7. ----------------------------------------------------- RFC 3095, 4.5.6, p.35-36 describes how to encode a 29-bit value in 1 to 4 octets. The ROHC Implementer's Guide, version 3, says this: ----------------------------------------------------- 4.2.1. Encoding of TS values RTP Timestamp values (TS) are always encoded using W-LSB encoding, both when sent scaled and when sent unscaled. For TS values sent in Extension 3, W-LSB encoded values are sent using the self-describing variable-length format (section 4.5.6), and this applies to both scaled and unscaled values. ----------------------------------------------------- Scenario: Suppose TS is unscaled and TS = 0x80000000. The lower 29 bits of TS are 0x00000000 = 0. Therefore the variable-length encoding gives a 1-octet encoding as 0x00. The remaining 3 bits (1, 0, 0) must now go in the main header, e.g. in a UOR-2 header. Question: How should the decompressor interpret the 3 bits 100 (binary) and the variable-length value 0x00 ? Either: 1. The decompressor may say that this value is 100 0000000 binary, because the 0x00 is a 7-bit zero. Or: 2. The decompressor may say that all TS values in extension 3 must represent 29 bits, and therefore the value is 100 00000 00000000 00000000 00000000 (binary). W-LSB encoded TS > 0x1ffffff is unlikely, but it is not impossible. My suggestion is that interpretation 2 should be adopted. Is it obvious from RFC 3095 that this must be so? Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jun 26 14:54:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14860 for ; Thu, 26 Jun 2003 14:54:25 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFf6d15383 for rohc-archive@odin.ietf.org; Wed, 25 Jun 2003 11:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCON-0003yg-9W for rohc-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:41:03 -0400 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 LAA16642 for ; Wed, 25 Jun 2003 11:41:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCNp-0003r9-Gd; Wed, 25 Jun 2003 11:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VByB-0008AG-NR for rohc@optimus.ietf.org; Wed, 25 Jun 2003 11:13:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11704 for ; Wed, 25 Jun 2003 02:04:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V3Oj-0002CA-00 for rohc@ietf.org; Wed, 25 Jun 2003 02:04:49 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19V3OY-0002C4-00 for rohc@ietf.org; Wed, 25 Jun 2003 02:04:38 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h5P64JH12386; Tue, 24 Jun 2003 23:04:19 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 24 Jun 2003 23:04:18 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ROHC mailing list cc: "Wijnen, Bert (Bert)" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote: Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt Bert> in the next week or two? >>>>> On Fri, 13 Jun 2003, C. M. Heard replied: CMH> I will volunteer to do this. Based on a quick look I think CMH> I should be able to turn around the review before June 26th. As noted above, I've volunteered to do a MIB Doctor review of . For the most part, I have been pleased with the quality of that document. However, there are a number of things that do need to be corrected, or at least looked at, before the document goes to the IESG. The detailed review comments below follow the checklist from Appendix A of the draft guidelines document . Those who wish to respond to these review comments should do so on the ROHC mailing list, with copies to Bert Wijnen and myself. 0.) Title -- s/Robus/Robust/ 1.) I-D Boilerplate -- OK 2.) Abstract -- acronyms used in the abstract must be expanded on first use, except for those acronyms that everyone in the IETF can reasonably be expected to know (see Sections 4.5 and 2.9 of or its successor document). Certainly ROHC and LLA will need to be expanded; I'm not sure about ESP and RTP -- please check with the RFC Editor. Here is a partial fix: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). [ ... ] The remainder is left to the authors to sort out. 3.) MIB Boilerplate -- OK 4.) IPR Notices -- the required notices from RFC 2026 Sections 10.4(A) and 10.4(B) are present and no claims are noted; this is OK if indeed there are no relevant IPR disclosures. Note, however, that a search of the IPR statements on the IETF web site does reveal some claims that seem like they _might_ be relevant: Search Results for query = '(robust or robustness or robustly) and (header or head or headed or heading or headings or heads or headers) and (compression or compressions)' _________________________________________________________________ Match: [All....] Format: [Long.] Sort by: [Title........] Refine search: ______________________________ Search _________________________________________________________________ Documents 1 - 4 of 11 matches. More * 's indicate a better match. _________________________________________________________________ [ERICSSON-ROCCO] * ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE UNDERTAKING In the AVT Working Group in the Internet Engineering Task Force, a proposal "RObust Checksum-based header COmpression (ROCCO)" dated June 22, 1999 has been made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at Lulea University ... http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557 bytes [ERICSSON-SIGCOMP.txt] * * * * ... that might possibly have technical relations to the Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt. This draft is part of the Signaling Compression work taking place in the Robust Header Compression (ROHC) WG. See further Ericsson's general IPR statement: http://www.ietf.org/ietf/IPR/ERICSSON ... http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02, 466 bytes [NOKIA-RFC3095.txt] * ... : 1) "CID field handling in ROHC": FI 20002100, US 09/954562, PCT/FI01/00819 2) "Variable length context identifier for real time header compression": FI 20002307, US 09/978479, PCT/FI01/00902 3) "Variable length encoding of compressed data": US 09/536638, US 60/164330, ... http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02, 1373 bytes [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] * ... This is to advise the IETF that Telefonaktiebolaget LM Ericsson believes it owns patents and patent applications which may relate to RFC 3095, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed". See further Ericsson's general IPR statement: http://www.ietf.org/ietf/IPR/ERICSSON ... http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST- HEADER-COMPRESSION.txt 09/27/02, 439 bytes Return to the Seach Page _________________________________________________________________ ht://Dig 3.1.6 The document authors and the WG should examine these IPR disclosures and either determine for sure that none are required in order to implement the MIB module or else add the notice from RFC 2026 Section 10.4(D). (The reviewer will be satisfied if the authors reply that the IPR section in the document is OK as it stands. All that's being requested is an assurance that you have done your homework.) 5.) References -- there are some missing normative references and some of the existing references contain minor errors or don't exactly follow the current RFC style. The style issues are listed only for completeness; RFC Editor will fix that in any case. (a) RFC 3411 needs to be added as a normative reference since SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB (c.f. Section 3.5). (b) RFC 2863 needs to be added as a normative reference since IF-MIB appears in the IMPORTS statement of all three MIB modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB. (c) [RFC3095] has an incorrect title and an author list that's not in the standard form. (d) [RFC3242] has an author list that's not in the standard form. (e) [RFCXXXX] has an author list that's not in the standard form, and it might be helpful to readers to indicate the I-D that will eventually turn into this RFC-to-be. 6.) Security Considerations Section -- there are two read/write objects but only one is mentioned. A possible fix would be to revise the first paragraph to read as follows: The managed objects defined by the ROHC-MIB module, the ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not have a MAX-ACCESS value of read-write and/or read-create except rohcInstanceContextStorageTime and rohcContextStorageTime, both of which have a MAX-ACCESS value of read-write. These objects determine how long context information is stored after its termination. Unauthorized access to these objects can have one of two negative effects. If they are set to a value lower than required, e.g. to zero, then context information about past contexts might get lost. If they are set to a very high value, then context information will not be deleted and memory consumption of the agent implementation might become very high. However, unauthorized access to these objects cannot cause harm to existing ROHC connections nor can it allow manipulation of running instances of ROHC in a malicious way. The fourth paragraph says "[a]lthough the security risks arising from the ROHC-MIB module are not considered to be high", but the second paragraph says "[it is] important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP." That seems contradictory. It is therefore suggest to modify the fourth paragraph so that it reads as originally written in the standard security considerations template: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). 7.) IANA Considerations Section -- OK (none present and none required). 8.) Copyright notices -- the abbreviated copyright notices that are supposed to appear on the front page and in the DESCRIPTION clause of each MODULE-IDENTITY invocation are missing and need to be added. See http://www.ietf.org/ID-nits.html section 1.2, section 4.3, and section 3.8. 9.) MIB compilation -- the following problems are reported by smilint: This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) has been processed to get the following results: smilint -m -s -l 6 -i namelength-32 ROHC-MIB ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-MIB:184: [5] {index-element-accessible} warning: index element `rohcInstanceType' of row `rohcInstanceEntry' should be not-accessible in SMIv2 MIB FIXES: (a) add Counter32 to the list of things imported from SNMPv2-SMI (b) change MAX-ACCESS value of rohcInstanceType to not-accessible (c) remove rohcInstanceType from rohcInstanceGroup This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) has been processed to get the following results: smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI FIX: add Counter32 to the list of things imported from SNMPv2-SMI This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) has been processed to get the following results: smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type `Counter32' must be imported from SNMPv2-SMI FIX: add Counter32 to the list of things imported from SNMPv2-SMI 10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html that is not covered above: (a) there are several places in the MIB modules where the lines extend beyond column 72. Most (but not all) of these could be fixed by eliminating the three-space indentation. Althought the RFC Editor can probably do this, it will save time and reduce the proabability of formatting errors in the final RFC if the authors would fix it themselves. See ID-nits section 1.1. (b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to the list of imperatives (although the standard boilerplate in RFC 2119 does not include it, it is used in the Security Considerations section and it is defined in RFC 2119). (c) in Section 3, "Overview", 3rd paragraph: s/means/a means/ (d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/ (e) in Section 4, "Structure of the MIB modules", 1st paragraph: s/Section 6/Section 5/ (f) in Section 4, "Structure of the MIB modules", 2nd and 4th paragraphs: most acronyms must be expanded upon first use, except for those that everyone in the IETF can reasonably be expected to know. Note that this rule applies separately for the body of the memo and the abstract; see Sections 4.7 and 2.9 of or its successor document and review comment (2) above. (g) in Section 4.1, "The ROHC-MIB module", first paragraph: the tables are mentioned in a different order than they appear in the MIB module, which has rohcChannelTable before rohcInstanceTable. Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with the order in this paragraph but are "swapped" relative to the MIB module. It might be better if the order in the text matched that of the MIB module. (h) in Section 4.1, "The ROHC-MIB module", last paragraph: unexpanded acronym CID. (i) in Section 4.1.1, "rohcInstanceTable", 4th bullet: s/storagetime/storage time/ (j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed text from: o the state of the CID ('unused', 'active', 'expired', or to: o the state of the CID ('unused', 'active', 'expired', or 'terminated'. Note: a common cause of missing text in an I-D is a line in the nroff source that starts with a single quote as the first character of the line. 11.) Technical content -- the following comments pertain to the material in Sections 3, 4, and 5. Please note that I am not an ROHC subject matter expert and so I do not have the knowledge to attempt a detailed verification that the MIB objects are indeed fit for the intended purposes. I'm presuming that the WG has already done that, so I've concentrated on MIB design issues. Issues already covered under (9) above won't be repeated here. (a) in Section 3, "Overview", next to last paragraph, it is stated that "the compressor context can be reinitialized." I didn't see any read-write or read-create objects in the MIB module that would support such a capability. If indeed there is no support for such a capability then the claim should be removed. (b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3, "rohcProfileTable", and also in the corresponding definitions in the ROHC-MIB module in Section 5: it is not clear why one needs a vendor, version number, and implementation description in both of these tables. Indeed, except for the descriptors and OIDs that are assigned, the definitions of rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr are identical with those for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr (respectively). It seems to me that the objects rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr could be eliminated without loss of capability. The designers may also wish to consider moving rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into the rohcChannelTable or perhaps even turning them into scalars. (c) in Section 4.1.3, "rohcProfileTable", there is no mention of the per-profile Boolean flag that indicates whether the profile has been negotiated to be used at the instance. (d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations need to be changed in the following ways: - WG mailing list info (and optionally, charter page URL) needs to be present in the CONTACT-INFO clause; - there needs to be a REVISION/DESCRIPTION clause pair with a date identical to that in the LAST-UPDATED clause and a description indicating that the module is the initial published version; - the DESCRIPTION clause needs to include an abbreviated copyright notice (per (8) above). See sections 3.8 and 4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY invocation could be changed from: rohcMIB MODULE-IDENTITY LAST-UPDATED "200209251358Z" ORGANIZATION "IETF Robust Header Compression Working Group" CONTACT-INFO "Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 34 69221 Heidelberg Germany Tel: +49 6221 90511-15 E-mail: quittek@ccrle.nec.de" DESCRIPTION "This MIB module defines a set of basic objects for monitoring and configuring robust header compression. The module covers information about running instances of ROHC (compressors or decompressors) at IP interfaces. Information about compressor contexts and decompressor contexts has different structure for different profiles. Therefore it is not provided by this MIB module, but by individual modules for dofferent profiles." ::= { mib-2 XXX } -- XXX to be assigned by IANA. to something along the lines of: rohcMIB MODULE-IDENTITY LAST-UPDATED "200306250000Z" -- June 25, 2003 ORGANIZATION "IETF Robust Header Compression Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/rohc-charter.html Mailing Lists: General Discussion: rohc@ietf.org To Subscribe: rohc-request@ietf.org In Body: subscribe your_email_address Editor: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 34 69221 Heidelberg Germany Tel: +49 6221 90511-15 E-mail: quittek@ccrle.nec.de" DESCRIPTION "This MIB module defines a set of basic objects for monitoring and configuring robust header compression. The module covers information about running instances of ROHC (compressors or decompressors) at IP interfaces. Information about compressor contexts and decompressor contexts has different structure for different profiles. Therefore it is not provided by this MIB module, but by individual modules for different profiles. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice REVISION "200306250000Z" -- June 25, 2003 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice ::= { mib-2 XXX } -- XXX to be assigned by IANA. with the dates changed as appropriate. [Note also a typo fix: s/dofferent/different/.] Similar changes apply to the other MIB modules. (e) in Section 5, all MIB modules: the ordering of the index components is not consistent throughout. Specifically, although all tables are indexed by ifIndex and rohcChannelID, the tables without rohcInstanceType as an index component all have { ifIndex, rohcChannelID, ... } as a common prefix, while those with rohcInstanceType do not: their common prefix is { ifIndex, rohcInstanceType, rohcChannelID, ... }. While this will certainly work, and may be legitimate if one wishes to have a different sort order in different tables, the MIB designers should be aware that it tends to make the implementation harder than it otherwise would be, because there is less indexing code that can be shared between different tables. Unless there was a specific reason for choosing the specific index order that is in the draft, the authors may wish to consider changing the order of the leading components in the tables that have rohcInstanceType as an index component from: INDEX { ifIndex, rohcInstanceType, rohcChannelID, ... } to: INDEX { ifIndex, rohcChannelID, rohcInstanceType, ... } The affected row objects are rohcInstanceEntry and rohcContextTable in the ROHC-MIB module, rohcUncmprContextEntry in the ROHC-UNCOMPRESSED-MIB module, and rohcRtpContextTable and rohcRtpPacketSizeEntry in the ROHC-RTP-MIB module. (f) in Section 5, all MIB modules: none of the Counter32 objects has a discontinuity time indicator. Such an indicator is required if events other than a reboot may result in a discontinuity (i.e., non-monotonic counting behaviour); see the first bullet of Section 4.6.1.2 of . Since each counter is associated with a specific interface, a good solution in this case is to use IF-MIB's ifCounterDiscontinuityTime for this purpose, as is done in the EtherLike-MIB (RFC 2665), the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That would mean adding the following or similar text Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. to the DESCRIPTION clause of each of the Counter32 objects. (g) in Section 5, all MIB modules: it is observed that many objects are defined with SYNTAX values of of Integer32 (0..2147483647), Integer32 (1..2147483647), and Integer32 (0..1000). While this is certainly acceptable, it is brought to the authors' attention that Unsigned32 is preferred when the range of values is non-negative; see Section 4.6.1.1. Changes, if any, are left to the authors' discretion. (Note: current usage is consistent for all objects; if a change is made, please be sure to do so everywhere; but see 11(m) first.) /********** The following comments apply to the ROHC-MIB **********/ (h) In the DESCRIPTION clause of rohcChannelID it says: The value is expected to remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. I know that this same language is used in the IF-MIB, but it turns out that indices that don't remain fixed across reboots can lead to problems. See the thread "Referential integrity across reboots" at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140 Suggested remedy: change the above text to: The value is REQUIRED to remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. It is RECOMMENDED that the value persist across such re-initializations. (i) In the DESCRIPTION clause of rohcChannelFeedbackFor: s/feddback/feedback/ (j) In the following object definition it is not specified what value the object should assume if there is no feedback channel: rohcInstanceFBChannelID OBJECT-TYPE SYNTAX RohcChannelIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "Identifier of the channel used for feedback." ::= { rohcInstanceEntry 4 } Shouldn't the DESCRIPTION clause state that the value 0 is used in that case? It would seem to be consistent with the instructions in the RohcChannelIdentifier DESCRIPTION clause to do this. (k) In the following object definition: rohcInstanceMRRU OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum reconstructed reception unit. This is the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments (see RFC 3095, Section 5.2.5). Note that this size includes the CRC. If MRRU is negotiated to be 0, no segment headers are allowed on the channel." REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcInstanceEntry 11 } the SYNTAX value and the DESCRIPTION clause are at odds. FIX: change the SYNTAX value to Integer32 (0..2147483647) (l) In the following object definition: rohcInstanceContextsCurrent OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of currently active contexts created by this instance." ::= { rohcInstanceEntry 15 } a more appropriate SYNTAX value would be Integer32 (0..2147483647) since the number of contexts cannot possibly be negative. (m) In the following object definition: rohcInstanceCompressionRatio OBJECT-TYPE SYNTAX Integer32 (0..1000) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the compression ratio so far over all packets on the channel served by this instance. The value is defined as 1000 * bytes(compressed) / bytes(original) rounded to the next integer value. The number of bytes corresponds to all bytes of all IP packets including the IP header but excluding all lower layer headers." ::= { rohcInstanceEntry 20 } Is it theoretically possible for the compression ratio to exceed unity in certain unfavorable cases? If so, then the range needs to be changed to allow for that, or the DESCRIPTION clause needs to state that the value is set to 1000 if the actual compression ratio exceeds unity. In the latter case a more appropriate SYNTAX value would be Gauge32 (0..1000) (see Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION RATIO OBJECTS. (n) I'm not sure if I properly understood the DESCRIPTION clause of the following object: rohcProfileNegotiated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When retrieved, this boolean object returns true if the profile has been negotiated to be used at the instance, i.e. is supported also by the corresponding compressor/decompressor." ::= { rohcProfileEntry 7 } My understanding is that an instance of this object corresponding to a particular triple should have the value true(1) if and only if at least one context with the same values is using that profile -- in other words, if and only if some instance of rohcContextProfile for the same values is equal to the rohcProfile value. If this understanding is _not_ correct, then clarification of the DESCRIPTION clause would be in order. (o) Several DESCRIPTION clauses in the ROHC-MIB refer to the non-existent object rohcContextType. They should refer instead to rohcInstanceType. The objects in question are: rohcContextDecompressorDepth rohcContextDecompressorFailures rohcContextDecompressorRepairs (p) In the following object definition [n.b. the above correction has been assumed to be applied]: rohcContextDecompressorDepth OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether reverse decompression, for example as described in RFC 3095, Section 6.1, is used on this channel or not, and if used, to what extent. Its value is only valid for decompressor contexts, i.e. if rohcInstanceType has the value decompressor(2). The value of the reverse decompression depth indicates the maximum number of packets that are buffered, and thus possibly be reverse decompressed by the decompressor. A zero (0) value means that reverse decompression is not used." ::= { rohcContextEntry 7 } it is not clear whether this object should have the value 0 for compressor contexts, or whether it should not be instantiated at all for such contexts. (q) The rohcCompliance DESCRIPTION clause should mention that the ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of , last paragraph before end note. Examples may be found in the dot3Compliance2 statement in , the mauModIfCompl3 statement in , or the etherWisCompliance in (although it is requested that the embedded citations be avoided). /*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/ (r) The rohcUncmprCompliance DESCRIPTION clause should mention that the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as prerequisites. See 11(q) above for examples. /******** The following comments apply to the ROHC-RTP-MIB ********/ (s) The DESCRIPTION clauses of several columnar objects in the rohcRtpContextTable state that those objects are valid only for certain profiles or for certain contexts. The objects in question are: rohcRtpContextAlwaysPad rohcRtpContextLargePktsAllowed rohcRtpContextVerifyPeriod rohcRtpContextSizesAllowed rohcRtpContextSizesUsed If the intent is that those objects are to be instantiated only for the profiles or contexts to which they apply, then that fact should be made explicit in the DESCRIPTION clauses. (t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and rohcRtpContextSizesUsed both appear to have the same three typographical errors: rohcRtpContextSizesAllowed OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is only valid for decompressor contexts, i.e. if rohcContextType of the cooresponding ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ rohcContextEntry has the value compressor(2). ^^^^^^^^^^^^^ This object contains the number of different packet sizes that may be used in the context." REFERENCE "RFC 3095, Section 6.3.1" ::= { rohcRtpContextEntry 10 } rohcRtpContextSizesUsed OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is only valid for decompressor contexts, i.e. if rohcContextType of the cooresponding ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ rohcContextEntry has the value compressor(2). ^^^^^^^^^^^^^ This object contains the number of different packet sizes that are used in the context." REFERENCE "RFC 3095, Section 6.3.1" ::= { rohcRtpContextEntry 11 } Suggested fixes: s/rohcContextType/rohcInstanceType/ s/cooresponding/corresponding/ s/compressor(2)/decompressor(2)/ (u) There are some design issues with the rohcRtpPacketSizeTable: - the index column rohcRtpPacketSize with has values in the range 0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive integers, i.e., the value 0 is excluded as it does not make sense. FIX: change the range to 1..2147483647. (This also avoids running afoul of the SMIv2 rule that index values of zero should be avoided, except in special cases.) - the TruthValue column rohcRtpPacketSizeAllowed seems to be unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that "packet sizes not in the set of values for [PACKET_SIZES_ALLOWED] MUST NOT be used", it seems that an agent would never need to instantiate any of the other columns if rohcRtpPacketSizeAllowed had the value false(2). In other words, any row for which this objects is false should simply be absent from the table. (v) The rohcRtpCompliance DESCRIPTION clause should mention that the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as prerequisites. See 11(q) above for examples. This concludes the review of . Regards, Mike Heard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 30 07:54:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12678 for ; Mon, 30 Jun 2003 07:54:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UBrWf07751 for rohc-archive@odin.ietf.org; Mon, 30 Jun 2003 07:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxDw-00020w-D6 for rohc-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 07:53:32 -0400 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 HAA12476 for ; Mon, 30 Jun 2003 07:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxDQ-0001xd-F3; Mon, 30 Jun 2003 07:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxCj-0001vX-QD for rohc@optimus.ietf.org; Mon, 30 Jun 2003 07:52:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12112; Mon, 30 Jun 2003 07:52:16 -0400 (EDT) Message-Id: <200306301152.HAA12112@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 30 Jun 2003 07:52:16 -0400 Subject: [rohc] I-D ACTION:draft-west-sctp-epic-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SCTP Profile for EPIC Author(s) : M. West, A. Surtees Filename : draft-west-sctp-epic-01.txt Pages : 27 Date : 2003-6-27 This draft describes a profile for compressing SCTP/IP using the Robust Header Compression Formal Notation. The RObust Header Compression [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. This profile describes a new profile for ROHC which will allow SCTP/ IP headers to be compressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-west-sctp-epic-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-west-sctp-epic-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-west-sctp-epic-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27150521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-west-sctp-epic-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-west-sctp-epic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150521.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jun 30 07:56:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13282 for ; Mon, 30 Jun 2003 07:56:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UBtWU09528 for rohc-archive@odin.ietf.org; Mon, 30 Jun 2003 07:55:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxFs-0002Tb-HH for rohc-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 07:55:32 -0400 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 HAA13145 for ; Mon, 30 Jun 2003 07:55:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxFN-0002K7-CM; Mon, 30 Jun 2003 07:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxEQ-000283-9C for rohc@optimus.ietf.org; Mon, 30 Jun 2003 07:54:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12670; Mon, 30 Jun 2003 07:54:00 -0400 (EDT) Message-Id: <200306301154.HAA12670@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 30 Jun 2003 07:54:00 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-impl-guide-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Implementer's Guide for SigComp Author(s) : A. Surtees et al. Filename : draft-ietf-rohc-sigcomp-impl-guide-01.txt Pages : 9 Date : 2003-6-27 This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-impl-guide-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27150857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-impl-guide-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150857.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc