From exim@www1.ietf.org Sun Nov 2 00:52:21 2003 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 AAA25292 for ; Sun, 2 Nov 2003 00:52:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGB9g-00079w-5u for rohc-archive@odin.ietf.org; Sun, 02 Nov 2003 00:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA25q4fv027514 for rohc-archive@odin.ietf.org; Sun, 2 Nov 2003 00:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGB9g-00079h-2U for rohc-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 00:52:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25274 for ; Sun, 2 Nov 2003 00:51:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGB9d-0002I5-00 for rohc-web-archive@ietf.org; Sun, 02 Nov 2003 00:52:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGB9c-0002I1-00 for rohc-web-archive@ietf.org; Sun, 02 Nov 2003 00:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGB9c-00079O-CI; Sun, 02 Nov 2003 00:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGB8p-000798-Ox for rohc@optimus.ietf.org; Sun, 02 Nov 2003 00:51:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25264 for ; Sun, 2 Nov 2003 00:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGB8m-0002Ho-00 for rohc@ietf.org; Sun, 02 Nov 2003 00:51:08 -0500 Received: from bay10-f19.bay10.hotmail.com ([64.4.37.19] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AGB8m-0002HX-00 for rohc@ietf.org; Sun, 02 Nov 2003 00:51:08 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 1 Nov 2003 21:50:37 -0800 Received: from 80.74.106.2 by by10fd.bay10.hotmail.msn.com with HTTP; Sun, 02 Nov 2003 05:50:37 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [johnyjsmith1970@hotmail.com] From: "John Smith" To: rohc@ietf.org Date: Sun, 02 Nov 2003 05:50:37 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Nov 2003 05:50:37.0449 (UTC) FILETIME=[3D74F790:01C3A105] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA25265 Subject: [rohc] SigComp States Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm studying now SigComp and wondering about some issues: (1) Quoting from draft-ietf-roch-sigcomp-sip-00.txt (section 3): =93Usual= ly,=20 any states created during the lifetime of a compartment will be "logicall= y"=20 deleted when the compartment is closed. A logical deletion becomes a=20 physical one when all the compartments that created the (same) state are=20 closed.=94 When do compartments share the same state? When do different=20 compartments become related to the same state? (2) Quoting from RFC 3320 (section 6.2): =93Each instance of the UDVM can= pass=20 up to four state creation requests to the state handler=85=94 Why does a = UDVM=20 need more than a single allocated state item? (3) Continuing the quote from the previous question: =93When the state ha= ndler=20 receives a state creation request from the UDVM it takes the following=20 steps: =85 3. If the state creation request contains a state_identifier = that=20 already exists=85=94 Is there any clear example to this kind of situation= ? I would appreciate any piece of information. Thanks, John. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.=20 http://join.msn.com/?page=3Dfeatures/virus _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Nov 3 10:44:23 2003 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 KAA07475 for ; Mon, 3 Nov 2003 10:44:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgs8-00050P-GH for rohc-archive@odin.ietf.org; Mon, 03 Nov 2003 10:44:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Fi4ZN019235 for rohc-archive@odin.ietf.org; Mon, 3 Nov 2003 10:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgs8-00050A-AQ for rohc-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 10:44:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07443 for ; Mon, 3 Nov 2003 10:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgs5-0007RU-00 for rohc-web-archive@ietf.org; Mon, 03 Nov 2003 10:44:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGgs5-0007RQ-00 for rohc-web-archive@ietf.org; Mon, 03 Nov 2003 10:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgs6-0004zt-21; Mon, 03 Nov 2003 10:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgrf-0004u7-OW for rohc@optimus.ietf.org; Mon, 03 Nov 2003 10:43:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07425 for ; Mon, 3 Nov 2003 10:43:23 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgrd-0007Qy-00 for rohc@ietf.org; Mon, 03 Nov 2003 10:43:33 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AGgrc-0007Qv-00 for rohc@ietf.org; Mon, 03 Nov 2003 10:43:32 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA3FhVF15681 for ; Mon, 3 Nov 2003 17:43:31 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 17:43:31 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 09:42:55 -0600 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] SigComp States X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 3 Nov 2003 10:42:53 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E896@ajebe001.americas.nokia.com> Thread-Topic: [rohc] SigComp States Thread-Index: AcOhBX1fTpk9LZpgTVWeTz0oMBbiXABGL0OA To: , X-OriginalArrivalTime: 03 Nov 2003 15:42:55.0287 (UTC) FILETIME=[26127470:01C3A221] 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 Hello John, Thanks for comments on sigcomp-sip. Please see my reply inline. BR, Zhigang > (1) [snip] When do compartments share the same state? When do=20 > different compartments become related to the same state? There are two possible cases: a) two compartments accidentally creates the same state without knowing it, and b) they intentionally create the same state. The chance of a) may be small in practice, but a sigcomp implementation must be able to handle it correctly. Case b) is more like a state "sharing". An example could be multiple compartments (from the same sigcomp implementation) share a state of bytecode or dictionary. > (2) [snip] Why does a UDVM need more than a single allocated state = item? The compressor may want to create more than one state in a sigcomp message, e.g., one state containing bytecode and one containing=20 dictionary. Of course, this is up to implementation. It may just create one state. The purpose is to make SigComp reasonably flexible without compromise security. > (3) [snip] 3. If the state creation request contains a=20 > state_identifier that already exists..." Is there any clear=20 > example to this kind of situation? An example could be for sigcomp over UDP. A compressor may try to create the same state in two sigcomp messages before it knows whether or not the first sigcomp message is received at the other endpoint. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 4 02:47:21 2003 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 CAA02395 for ; Tue, 4 Nov 2003 02:47:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvu3-00045y-DB for rohc-archive@odin.ietf.org; Tue, 04 Nov 2003 02:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA47l3x6015733 for rohc-archive@odin.ietf.org; Tue, 4 Nov 2003 02:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvu3-00045V-74 for rohc-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 02:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02368 for ; Tue, 4 Nov 2003 02:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvtz-0000BT-00 for rohc-web-archive@ietf.org; Tue, 04 Nov 2003 02:46:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGvty-0000BP-00 for rohc-web-archive@ietf.org; Tue, 04 Nov 2003 02:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvu1-00044O-VS; Tue, 04 Nov 2003 02:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvt2-00040b-T1 for rohc@optimus.ietf.org; Tue, 04 Nov 2003 02:46:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02325 for ; Tue, 4 Nov 2003 02:45:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvsy-0000AP-00 for rohc@ietf.org; Tue, 04 Nov 2003 02:45:56 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AGvsy-0000A2-01 for rohc@ietf.org; Tue, 04 Nov 2003 02:45:56 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 2 Nov 2003 23:19:36 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRP20L; Sun, 2 Nov 2003 23:19:32 -0000 From: "West, Mark" To: rohc@ietf.org Date: Sun, 2 Nov 2003 23:19:31 +0000 (GMT Standard Time) Message-ID: X-X-Sender: maw1@maw-laptop.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] The new 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: , Hi all, This seems like as good an opportunity as any to summarise the changes we've made in the notation since last time around... ... and they're pretty substantial! There is a fundamental change to the philosophy of the notation: previously we have tried to describe the packet formats and how to compress each field -- the compressed packet formats were derived in some (standardised way) from this description. After some intense discussion, and given that this seemed to involve standardising some non-trivial algorithms, we have taken an different approach. Now, the aim is to describe the uncompressed packet format; the compressed packet formats; and the mapping between these two. That is, the notation is now focussed on describing the compressed packet formats (rather than a description that can be used to generate packet formats). It is perhaps easiest to explain the changes by comparison... Previous form: foo ::= bar baz bar ::= static / irregular(8) baz ::= value(8, 0) / value(8, 1) would have given rise to the 4 packet formats: bar[static] + baz[value(8,0)] bar[static] + baz[value(8,1)] bar[irregular(8)] + baz[value(8,0)] bar[irregular(8)] + baz[value(8,1)] and probabilities would be used to assign indicators to these formats in some standardised form (e.g. EPIC or EPIC-lite). All change! The new form captures formats: we can define the uncompressed format and capture (say) 3 packet formats as: foo ::= compressed_packet_formats, { co_formats ::= constant(3), % this is the first packet format % note that the 8-bit discriminator is chosen % simply to byte-align the packets... co_format_0 ::= discriminator, % 8 bits { discriminator ::= '00000000', bar ::= static, baz ::= value(8,0) }, co_format_1 ::= discriminator, % 8 bits { discriminator ::= '00000001', bar ::= static, baz ::= value(8,1) } co_format_2 ::= discriminator, % 7 bits baz, % 1 bit bar, % 8 bits { discriminator ::= '0000001', bar ::= irregular(8), baz ::= index(8, [0, 1]) % 1-bit choice between 0/1 } uncompressed_format ::= foo, foo ::= bar, % 8 bits baz % 8 bits } [with a fair degree of elision...] You can see from the above (hopefully!) that there is no need to run any algorithm to generate packet formats: they are specified in full within the notation. In order to allow 'reasoning' about the correctness of the profile, and for test purposes, there is a prolog implementation to help things along... For more details, see the draft! Comments, as ever, welcome... ... and feel free to collar me for discussions at Minneapolis! Cheers, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 4 02:47:22 2003 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 CAA02405 for ; Tue, 4 Nov 2003 02:47:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvu3-00045x-CM for rohc-archive@odin.ietf.org; Tue, 04 Nov 2003 02:47:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA47l3PL015721 for rohc-archive@odin.ietf.org; Tue, 4 Nov 2003 02:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvu3-00045T-3u for rohc-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 02:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02365 for ; Tue, 4 Nov 2003 02:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvtz-0000BO-00 for rohc-web-archive@ietf.org; Tue, 04 Nov 2003 02:46:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGvty-0000BL-00 for rohc-web-archive@ietf.org; Tue, 04 Nov 2003 02:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvu1-00043Y-6u; Tue, 04 Nov 2003 02:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvt2-00040X-DN for rohc@optimus.ietf.org; Tue, 04 Nov 2003 02:46:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02322 for ; Tue, 4 Nov 2003 02:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvsy-0000AL-00 for rohc@ietf.org; Tue, 04 Nov 2003 02:45:56 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AGvsy-0000A2-00 for rohc@ietf.org; Tue, 04 Nov 2003 02:45:56 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 2 Nov 2003 22:12:16 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRP20A; Sun, 2 Nov 2003 22:12:11 -0000 From: "West, Mark" To: John Smith Cc: rohc@ietf.org Date: Sun, 2 Nov 2003 22:12:10 +0000 (GMT Standard Time) Subject: Re: [rohc] SigComp States In-Reply-To: Message-ID: References: X-X-Sender: maw1@maw-laptop.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Hi John, > > I'm studying now SigComp and wondering about some issues: > > (1) Quoting from draft-ietf-roch-sigcomp-sip-00.txt (section 3): = =93Usually, > any states created during the lifetime of a compartment will be = "logically" > deleted when the compartment is closed. A logical deletion becomes a > physical one when all the compartments that created the (same) state = are > closed.=94 When do compartments share the same state? When do = different > compartments become related to the same state? > Think about bytecode or an implementation-specific dictionary -- all instances of that particular implementation could create the same piece = of state or states. (My bytecode might save itself; all end-points = running this code will do the same thing). > (2) Quoting from RFC 3320 (section 6.2): =93Each instance of the UDVM = can pass > up to four state creation requests to the state handler=85=94 Why = does a UDVM > need more than a single allocated state item? > Again, think about saving bytecode or some non-standard (but cross-compartment) dictionary as well as the circular buffer. It is = easy to consider examples where 2 or more states are created in response to = a single message. You should also never lose sight of the fact that 3320 defines the decompressor. We neither know, nor particularly want to constrain, = what compression algorithms can be implemented. 4 state creation requests = seem to allow enough latitude... > (3) Continuing the quote from the previous question: =93When the = state handler > receives a state creation request from the UDVM it takes the = following > steps: =85 3. If the state creation request contains a = state_identifier that > already exists=85=94 Is there any clear example to this kind of = situation? > If one instance of an endpoint has created a piece of state (e.g. bytecode) the state will have a specific state identifier. If another instance creates the same piece of state it will have the same state identifier (obviously). This should be allowed to succeed (and will create the 'multiple compartments referencing the same state' of your first question). However, if some endpoint created a different piece = of state that happened to have the same state identifier (i.e. a hash collision), the state creation must fail (otherwise we would have an ambiguity in accessing state). Cheers, Mark. --=20 Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 5 05:14:19 2003 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 FAA29206 for ; Wed, 5 Nov 2003 05:14:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKfq-0007DL-H7 for rohc-archive@odin.ietf.org; Wed, 05 Nov 2003 05:14:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5AE2FH027725 for rohc-archive@odin.ietf.org; Wed, 5 Nov 2003 05:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKfp-0007D6-R9 for rohc-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 05:14:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29203 for ; Wed, 5 Nov 2003 05:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHKfm-0000iO-00 for rohc-web-archive@ietf.org; Wed, 05 Nov 2003 05:13:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHKfm-0000iJ-00 for rohc-web-archive@ietf.org; Wed, 05 Nov 2003 05:13:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKfo-0007Co-9Q; Wed, 05 Nov 2003 05:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHKf1-0007CC-N6 for rohc@optimus.ietf.org; Wed, 05 Nov 2003 05:13:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29177 for ; Wed, 5 Nov 2003 05:12:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHKey-0000i2-00 for rohc@ietf.org; Wed, 05 Nov 2003 05:13:08 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AHKex-0000hq-00 for rohc@ietf.org; Wed, 05 Nov 2003 05:13:07 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Nov 2003 10:12:38 -0000 Message-ID: From: "Surtees, Abigail" To: "'rohc@ietf.org'" Date: Wed, 5 Nov 2003 10:12:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [rohc] SigComp implementer's guide status Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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, The SigComp implementer's guide has not been updated for Minneapolis so still stands at version 01 (June 2003). There has been only one issue discussed on the list since then that should go into the next version. This is the issue of state retention priority (see http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01748.html and the responses). I'll propose some text to cover this issue (and any others that arise in the mean time) after Minneapolis. Best regards, Abbie Abbie Surtees Senior Engineer Networks Roke Manor Research Ltd Old Salisbury Lane Romsey, SO51 0ZN Tel: +44 (0) 1794 833131 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 5 11:36:21 2003 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 LAA12210 for ; Wed, 5 Nov 2003 11:36:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQdY-0003Pn-1k for rohc-archive@odin.ietf.org; Wed, 05 Nov 2003 11:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Ga4nx013128 for rohc-archive@odin.ietf.org; Wed, 5 Nov 2003 11:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQdX-0003Pf-Rg for rohc-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 11:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12198 for ; Wed, 5 Nov 2003 11:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQdW-0006d7-00 for rohc-web-archive@ietf.org; Wed, 05 Nov 2003 11:36:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHQdW-0006d4-00 for rohc-web-archive@ietf.org; Wed, 05 Nov 2003 11:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQdV-0003PD-Fs; Wed, 05 Nov 2003 11:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQcv-0003Ov-Ar for rohc@optimus.ietf.org; Wed, 05 Nov 2003 11:35:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12191 for ; Wed, 5 Nov 2003 11:35:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQcu-0006cs-00 for rohc@ietf.org; Wed, 05 Nov 2003 11:35:24 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AHQct-0006cp-00 for rohc@ietf.org; Wed, 05 Nov 2003 11:35:23 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA5GZL4t002848 for ; Wed, 5 Nov 2003 08:35:21 -0800 (PST) Received: from HAIPENGJ.qualcomm.com (haipengj.qualcomm.com [129.46.74.180]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA5GZK0O004407 for ; Wed, 5 Nov 2003 08:35:20 -0800 (PST) Message-Id: <5.2.0.9.2.20031104151256.00b309d8@E2k.qualcomm.com> X-Sender: haipengj@E2k.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Nov 2003 08:35:19 -0800 To: "Rohc (E-mail)" From: Haipeng Jin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rohc] Question about 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: , Hi, I am reading ROHC FN draft 02 and get confused about the following definitions: The "from_list" encoding method defined in 5.3.3 is used to extact the presence and order flags from a list of items encoded with the list_of_known_length encoding method. The order_flag and and presence_flag are all control fields defined in 5.4.3 to indicate whether there are changes of order and presence in the list_of_known_length. These are all clear. However, I am confused about their usage in the example shown at the end of 5.4.3. The relevant part of the example is copied as follows. list_eg ::= single_packet_format, { ... order_flag ::= control_field, { base_field ::= same_as(list_eg.list_of_fields.order_flag), compressed_method ::= irregular(1) }, presence_flag ::= control_field, { base_field ::= same_as (list_eg.list_of_fields.presence_flag), compressed_method ::= irregular(1) }, list_of_fields ::= list_of_known_length, { list_length ::= constant(8), order_flag ::= from_list(list_eg.order_flag), presence_flag ::= from_list(list_eg.presence_flag), ... } } This seems to be a circular definition. For example, list_eg.order_flag is same_as(list_eg.list_of_fields.order_flag), while list_eg.list_of_fields.order_flag is from_list(list_eg.order_flag). Could anyone please explain it to me? Have I misunderstood anything here? Thank you very much. Haipeng _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 5 18:22:18 2003 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 SAA00507 for ; Wed, 5 Nov 2003 18:22:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWyQ-0004V1-9P for rohc-archive@odin.ietf.org; Wed, 05 Nov 2003 18:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NM2pc017295 for rohc-archive@odin.ietf.org; Wed, 5 Nov 2003 18:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWyQ-0004Us-5g for rohc-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:22:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00483 for ; Wed, 5 Nov 2003 18:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWyN-0005Y5-00 for rohc-web-archive@ietf.org; Wed, 05 Nov 2003 18:21:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHWyM-0005Y2-00 for rohc-web-archive@ietf.org; Wed, 05 Nov 2003 18:21:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWyO-0004UG-JG; Wed, 05 Nov 2003 18:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWxU-0004RQ-Cp for rohc@optimus.ietf.org; Wed, 05 Nov 2003 18:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00443 for ; Wed, 5 Nov 2003 18:20:49 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWxR-0005XT-00 for rohc@ietf.org; Wed, 05 Nov 2003 18:21:01 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHWxQ-0005XK-00 for rohc@ietf.org; Wed, 05 Nov 2003 18:21:00 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5NL0Y05086 for ; Thu, 6 Nov 2003 01:21:00 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Nov 2003 01:20:58 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 17:20:39 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 5 Nov 2003 18:20:38 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808DC76@ajebe001.americas.nokia.com> Thread-Topic: sigcomp-sip status Thread-Index: AcOj82uEdIkP89vCSb2sE3u5gPMYOg== To: X-OriginalArrivalTime: 05 Nov 2003 23:20:40.0178 (UTC) FILETIME=[6D3FBD20:01C3A3F3] Content-Transfer-Encoding: quoted-printable Subject: [rohc] sigcomp-sip status Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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 Folks, The sigcomp-sip-00 has received few comments on the list (my thanks to those who have kindly provided their feedbacks, particularly Abbie, Jan, Pekka, and Robert).=20 The comments so far focus on the following issues: - Is 8K minimum DMS too large for SIP/SigComp? - Is 2K minimum SMS necessary? - Need for multiplexing SigComp messages and SIP messages on=20 the same TCP connection? Also, there has been little progress made on the compartment and state management. Since it seems to me that more discussions are needed on those issues,=20 the sigcomp-sip-00 was not updated for the Minneapolis meeting. I plan to update the I-D in December before it expires, hopefully with less issues open.=20 I would like to use this opportunity to encourage everyone to send your comments on this list.=20 BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 6 10:11:23 2003 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 KAA12161 for ; Thu, 6 Nov 2003 10:11:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlmr-0003jB-Qz for rohc-archive@odin.ietf.org; Thu, 06 Nov 2003 10:11:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6FB5RY014323 for rohc-archive@odin.ietf.org; Thu, 6 Nov 2003 10:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlmr-0003iw-N0 for rohc-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 10:11:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12095 for ; Thu, 6 Nov 2003 10:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlmp-0002Eh-00 for rohc-web-archive@ietf.org; Thu, 06 Nov 2003 10:11:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHlmp-0002Ed-00 for rohc-web-archive@ietf.org; Thu, 06 Nov 2003 10:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlmn-0003ic-MK; Thu, 06 Nov 2003 10:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlmj-0003iJ-4S for rohc@optimus.ietf.org; Thu, 06 Nov 2003 10:10:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12078 for ; Thu, 6 Nov 2003 10:10:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlmg-0002ET-00 for rohc@ietf.org; Thu, 06 Nov 2003 10:10:54 -0500 Received: from bay10-f39.bay10.hotmail.com ([64.4.37.39] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AHlmg-0002E9-00 for rohc@ietf.org; Thu, 06 Nov 2003 10:10:54 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Nov 2003 07:10:10 -0800 Received: from 80.74.106.2 by by10fd.bay10.hotmail.msn.com with HTTP; Thu, 06 Nov 2003 15:10:09 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [johnyjsmith1970@hotmail.com] From: "John Smith" To: rohc@ietf.org Date: Thu, 06 Nov 2003 15:10:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Nov 2003 15:10:10.0218 (UTC) FILETIME=[1209F8A0:01C3A478] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA12079 Subject: [rohc] Questions about SigComp over SIP Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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, I would like to develop SigComp over SIP, and find some issues unclear: 1. Quoting from RFC3486 (Compressing the Session Initiation Protocol): =93= The=20 presence of this parameter (comp=3Dsigcomp) in a URI indicates that the=20 request has to be compressed using SigComp, as defined in [2]=94 (section= no.=20 2). Then, below in section no.7 it continues with: =93If a SIP client sends a= =20 compressed request and the client transaction times out without having=20 received any response, the client SHOULD retry the same request without=20 using compression.=94 This quotation instructs us to send the same messa= ge=20 without specifying the following details: =B7 Is the parameter =91comp=3Dsigcomp=92 has to be removed from the orig= inal=20 request URI before re-sending the uncompressed SIP request message? =B7 In case that a SIP message has to be re-sent uncompressed, should it=20 contain different Via branch value (as it is done after transmission=20 failure, when using DNS) or different CSeq? 2. Is there any example of SigComp state that is created dynamically and = is=20 used by more than a single compartment? I=92m looking for an example of s= tate=20 that is not =91global=92 or created during initialization process (such a= s state=20 that keeps the dictionary or state that keeps compression/decompression=20 algorithm). 3. Do the compression/decompression algorithms instruct us which states a= nd=20 how many of them have to be created in order to support the SigComp featu= re?=20 or Does the states creation depend on the way that SigComp is implemented= ? I would appreciate answers to any of my questions. Thank You, John. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online=20 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 6 16:35:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02240 for ; Thu, 6 Nov 2003 16:35:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrmR-00059M-4R for rohc-archive@odin.ietf.org; Thu, 06 Nov 2003 16:35:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6LZ3nR019792 for rohc-archive@odin.ietf.org; Thu, 6 Nov 2003 16:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrmQ-000599-PY for rohc-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16:35:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02222 for ; Thu, 6 Nov 2003 16:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrmO-0000xv-00 for rohc-web-archive@ietf.org; Thu, 06 Nov 2003 16:35:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHrmO-0000xs-00 for rohc-web-archive@ietf.org; Thu, 06 Nov 2003 16:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrmP-00058j-5Q; Thu, 06 Nov 2003 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrm9-00058R-RY for rohc@optimus.ietf.org; Thu, 06 Nov 2003 16:34:45 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02219 for ; Thu, 6 Nov 2003 16:34:33 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AHrbh-0006ND-0O; Thu, 06 Nov 2003 16:23:57 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: rohc@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 06 Nov 2003 16:23:57 -0500 Subject: [rohc] Last Call: 'RObust Header Compression (ROHC): A Compression Profile for IP' to Proposed Standard Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Robust Header Compression WG to consider the following document: - 'RObust Header Compression (ROHC): A Compression Profile for IP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-05.txt _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 7 05:10:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08657 for ; Fri, 7 Nov 2003 05:10:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Z6-0005bW-Kd for rohc-archive@odin.ietf.org; Fri, 07 Nov 2003 05:10:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7AA4dv021538 for rohc-archive@odin.ietf.org; Fri, 7 Nov 2003 05:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Z5-0005bI-BI for rohc-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08645 for ; Fri, 7 Nov 2003 05:09:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Z1-0002R0-00 for rohc-web-archive@ietf.org; Fri, 07 Nov 2003 05:09:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3Z1-0002Qx-00 for rohc-web-archive@ietf.org; Fri, 07 Nov 2003 05:09:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Z3-0005ak-0w; Fri, 07 Nov 2003 05:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3YY-0005ZU-BO for rohc@optimus.ietf.org; Fri, 07 Nov 2003 05:09:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08630 for ; Fri, 7 Nov 2003 05:09:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3YU-0002Qb-00 for rohc@ietf.org; Fri, 07 Nov 2003 05:09:26 -0500 Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx with esmtp (Exim 4.12) id 1AI3YU-0002QH-00 for rohc@ietf.org; Fri, 07 Nov 2003 05:09:26 -0500 Received: from oleane ([194.250.212.114]) by smtp1.clb.oleane.net with SMTP id hA7A8tf0023876 for ; Fri, 7 Nov 2003 11:08:56 +0100 Message-ID: <040201c3a517$ad10dc20$0601a8c0@www.oleane.com> From: "M Winkhler" To: Date: Fri, 7 Nov 2003 11:12:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03FF_01C3A520.0E8157C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [rohc] WiMAX Summit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_03FF_01C3A520.0E8157C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are WiMAX and WiFi complementary (local vs. metropolitan area = networking)?=20 When and how will WiMAX evolve towards mobility?=20 Can WiMAX be considered as a migration path to 4G?=20 How is addressed the interoperability challenge?=20 These questions, among others, will be addressed during the WiMAX = Summit, to be held in Paris on May 25 to 28, 2004.=20 A call for papers has been launched on-line at: http://www.upperside.fr/wimax04/wimax04intro.htm ------=_NextPart_000_03FF_01C3A520.0E8157C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are WiMAX and WiFi complementary (local vs. = metropolitan=20 area networking)?
When and how will WiMAX evolve towards = mobility?=20
Can WiMAX be considered as a migration path to 4G?
How is = addressed the=20 interoperability challenge?

These questions, among others, will = be=20 addressed during the WiMAX = Summit, to=20 be held in Paris on May 25 to 28, 2004. =

A=20 call for papers has been launched on-line at:
http://www.uppe= rside.fr/wimax04/wimax04intro.htm
------=_NextPart_000_03FF_01C3A520.0E8157C0-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 7 08:44:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14065 for ; Fri, 7 Nov 2003 08:44:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI6uA-0006TC-7a for rohc-archive@odin.ietf.org; Fri, 07 Nov 2003 08:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Di2bQ024864 for rohc-archive@odin.ietf.org; Fri, 7 Nov 2003 08:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI6uA-0006Sx-3X for rohc-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 08:44:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14042 for ; Fri, 7 Nov 2003 08:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI6u8-00056L-00 for rohc-web-archive@ietf.org; Fri, 07 Nov 2003 08:44:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI6u8-00056I-00 for rohc-web-archive@ietf.org; Fri, 07 Nov 2003 08:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI6u8-0006Sh-UZ; Fri, 07 Nov 2003 08:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI6tG-0006N6-6o for rohc@optimus.ietf.org; Fri, 07 Nov 2003 08:43:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14002 for ; Fri, 7 Nov 2003 08:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI6tE-00055Z-00 for rohc@ietf.org; Fri, 07 Nov 2003 08:43:04 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AI6tE-00055G-00 for rohc@ietf.org; Fri, 07 Nov 2003 08:43:04 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 13:42:23 -0000 Message-ID: From: "Finking, Robert" To: "'rohc@ietf.org'" Date: Fri, 7 Nov 2003 13:42:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [rohc] RE: Question about 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: , Jin, Thanks for your question about "from_list" encoding. The whole of list encoding is certainly the most complicated aspect of the ROHC-FN proposal - thank you for taking the time to absorb it. The answer is fairly straightforward; the notation covers both the information needed for encoding and that needed for decoding. The "from_list" encoding method looks at both the compressed and uncompressed packet to see which it knows. If the uncompressed packet value (i.e. at the compressor), then the value is calculated from the uncompressed packet and associated context, as described in the FN draft. If the compressed packet value is known then the value is extracted directly from the compressed packet. This was not made explicit in the draft, thanks for highlighting the need for clarification on this point. As an aside, this technique is also used elsewhere. If you look at the contemporary TCP profile (http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt), in section 6.5.2. Default encoding methods, you will see that the notation for encoding a sequence number uses a similar technique. The definition appears to be circular: tcp_seq_number ::= derived_value, { field_length ::= constant(32), field_value ::= expression(uncomp(tcp_seq_number_scaled) * uncomp(tcp_payload_size) + uncomp(tcp_seq_number_residue)) }, ... tcp_seq_number_scaled ::= control_field, { base_field ::= expression(uncomp(tcp_ip.tcp_seq_number) // uncomp(tcp_ip.tcp_payload_size)), compressed_method ::= static }, tcp_seq_number_residue ::= control_field, { base_field ::= expression(uncomp(tcp_ip.tcp_seq_number) mod uncomp(tcp_ip.tcp_payload_size)), compressed_method ::= static }, ... Here we have sequence number defined in terms of scaled value and residue. We also have scaled value and residue defined in terms of sequence number. This looks circular, however one is use for compression and the other for decompression. If the value of a field is known a priori, then there is no need to calculate it. The obvious question is why this doesn't happen with all encoding techniques. The fact is that most of them are sufficiently simple that the two definitions of encoding and decoding behaviour are encapsulated within the encoding method. For example static encoding implicitly checks whether the field value in the uncompressed packet is known, if so, it doesn't need to do anything (since static encoding takes up zero bits in the compressed packet). If it doesn't know the uncompressed value of the field, then it is extracted from the context. The two behaviours are still there, they're just hidden to keep the notation simple. I hope this answers your question. Regards Robert Finking -----Original Message----- From: Haipeng Jin [mailto:haipengj@qualcomm.com] Sent: Wednesday, November 05, 2003 4:35 PM To: Rohc (E-mail) Subject: [rohc] Question about ROHC FN Hi, I am reading ROHC FN draft 02 and get confused about the following definitions: The "from_list" encoding method defined in 5.3.3 is used to extact the presence and order flags from a list of items encoded with the list_of_known_length encoding method. The order_flag and and presence_flag are all control fields defined in 5.4.3 to indicate whether there are changes of order and presence in the list_of_known_length. These are all clear. However, I am confused about their usage in the example shown at the end of 5.4.3. The relevant part of the example is copied as follows. list_eg ::= single_packet_format, { ... order_flag ::= control_field, { base_field ::= same_as(list_eg.list_of_fields.order_flag), compressed_method ::= irregular(1) }, presence_flag ::= control_field, { base_field ::= same_as (list_eg.list_of_fields.presence_flag), compressed_method ::= irregular(1) }, list_of_fields ::= list_of_known_length, { list_length ::= constant(8), order_flag ::= from_list(list_eg.order_flag), presence_flag ::= from_list(list_eg.presence_flag), ... } } This seems to be a circular definition. For example, list_eg.order_flag is same_as(list_eg.list_of_fields.order_flag), while list_eg.list_of_fields.order_flag is from_list(list_eg.order_flag). Could anyone please explain it to me? Have I misunderstood anything here? Thank you very much. Haipeng _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 7 13:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27956 for ; Fri, 7 Nov 2003 13:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBK2-0005PH-R3 for rohc-archive@odin.ietf.org; Fri, 07 Nov 2003 13:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7IR2qT020779 for rohc-archive@odin.ietf.org; Fri, 7 Nov 2003 13:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBK2-0005P4-Nm for rohc-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 13:27:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27944 for ; Fri, 7 Nov 2003 13:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBK0-0000r9-00 for rohc-web-archive@ietf.org; Fri, 07 Nov 2003 13:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBK0-0000r5-00 for rohc-web-archive@ietf.org; Fri, 07 Nov 2003 13:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBK1-0005Oo-8A; Fri, 07 Nov 2003 13:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBJ8-0005MP-RC for rohc@optimus.ietf.org; Fri, 07 Nov 2003 13:26:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27925 for ; Fri, 7 Nov 2003 13:25:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBJ5-0000qg-00 for rohc@ietf.org; Fri, 07 Nov 2003 13:26:03 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AIBJ4-0000qc-00 for rohc@ietf.org; Fri, 07 Nov 2003 13:26:02 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7IQ04t015705; Fri, 7 Nov 2003 10:26:00 -0800 (PST) Received: from HAIPENGJ.qualcomm.com (haipengj.qualcomm.com [129.46.74.180]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7IPwFB021543; Fri, 7 Nov 2003 10:25:59 -0800 (PST) Message-Id: <5.2.0.9.2.20031107100925.00b5e098@E2k.qualcomm.com> X-Sender: haipengj@E2k.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 07 Nov 2003 10:25:58 -0800 To: "Finking, Robert" , "'rohc@ietf.org'" From: Haipeng Jin Subject: Re: [rohc] RE: Question about ROHC FN In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Robert, Thank you for your explanation, that is very clear. I have another question about the encoding method "uncompressible". In ROHC FN 5.5.1, the example shows test_uncompressible ::= single_packet_format, { uncompressed_data ::= length, data, compressed_data ::= data, length ::= value(4, 1), data ::= uncompressible (test_uncompressible.length, 2, 2, 4) } I am wondering whether it actually should be data ::= uncompressible (test_uncompressible.length, 2, 2, -4). The uncompressible size of data should be (uncomp(test_uncompressible.length)/2)*2 - 4 instead of (uncomp(test_uncompressible.length)/2)*2 + 4, right? Also since you are mentioning ROHC-TCP, there seems to be an inconsistent in using "uncompressible" in the ROHC FN draft and ROHC TCP draft. Again, ROHC FN 5.5.1 says The encoding method takes four parameters. The first parameter gives the base value for calculating the length of the data, whilst the next three parameters specify a divisor, multiplier and offset which scale the variable so that it specifies the size of the uncompressible field in bits. So the uncompressible method is defined as uncompressible (base, divisor, multiplier, offset). While in ROHC-TCP 6.5.3, the generic format for compressing TCP option is given as: generic ::= single_packet_format, { uncompressed_data ::= kind, % 8 bits length, % 8 bits data_item, % data_size bits compressed_data ::= data_item, kind ::= static, length ::= static, data_item ::= uncompressible(tcp_ip.tcp_options.generic.length, 8, 1, -16) } } } }. If we use the definition for uncompressible in ROHC-FN, the data_item size will be (tcp_ip.tcp_options.generic.length)/8 - 16, but the actual size in bits should be (tcp_ip. ... .length)*8 - 16. Right? Thanks, Haipeng At 01:42 PM 11/7/2003 +0000, Finking, Robert wrote: >Jin, > >Thanks for your question about "from_list" encoding. The whole of list >encoding is certainly the most complicated aspect of the ROHC-FN proposal >- thank you for taking the time to absorb it. > >The answer is fairly straightforward; the notation covers both the >information needed for encoding and that needed for decoding. The >"from_list" encoding method looks at both the compressed and uncompressed >packet to see which it knows. If the uncompressed packet value (i.e. at >the compressor), then the value is calculated from the uncompressed packet >and associated context, as described in the FN draft. If the compressed >packet value is known then the value is extracted directly from the >compressed packet. This was not made explicit in the draft, thanks for >highlighting the need for clarification on this point. > >As an aside, this technique is also used elsewhere. If you look at the >contemporary TCP profile >(http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt), in >section 6.5.2. Default encoding methods, you will see that the notation >for encoding a sequence number uses a similar technique. The definition >appears to be circular: > > tcp_seq_number ::= derived_value, > { field_length ::= constant(32), > field_value ::= > expression(uncomp(tcp_seq_number_scaled) * > uncomp(tcp_payload_size) + > uncomp(tcp_seq_number_residue)) > }, > > ... > > tcp_seq_number_scaled ::= control_field, > > { base_field ::= > expression(uncomp(tcp_ip.tcp_seq_number) // > uncomp(tcp_ip.tcp_payload_size)), > compressed_method ::= static > }, > > tcp_seq_number_residue ::= control_field, > > { base_field ::= > expression(uncomp(tcp_ip.tcp_seq_number) mod > uncomp(tcp_ip.tcp_payload_size)), > compressed_method ::= static > }, > ... > >Here we have sequence number defined in terms of scaled value and residue. >We also have scaled value and residue defined in terms of sequence number. >This looks circular, however one is use for compression and the other for >decompression. If the value of a field is known a priori, then there is no >need to calculate it. > >The obvious question is why this doesn't happen with all encoding >techniques. The fact is that most of them are sufficiently simple that the >two definitions of encoding and decoding behaviour are encapsulated within >the encoding method. For example static encoding implicitly checks whether >the field value in the uncompressed packet is known, if so, it doesn't >need to do anything (since static encoding takes up zero bits in the >compressed packet). If it doesn't know the uncompressed value of the >field, then it is extracted from the context. The two behaviours are still >there, they're just hidden to keep the notation simple. > >I hope this answers your question. > >Regards > >Robert Finking > >-----Original Message----- >From: Haipeng Jin [mailto:haipengj@qualcomm.com] >Sent: Wednesday, November 05, 2003 4:35 PM >To: Rohc (E-mail) >Subject: [rohc] Question about ROHC FN > > >Hi, > >I am reading ROHC FN draft 02 and get confused about the following >definitions: > >The "from_list" encoding method defined in 5.3.3 is used to extact the >presence and order flags from a list of items encoded with the >list_of_known_length encoding method. The order_flag and and presence_flag >are all control fields defined in 5.4.3 to indicate whether there are >changes of order and presence in the list_of_known_length. These are all >clear. > >However, I am confused about their usage in the example shown at the end of >5.4.3. The relevant part of the example is copied as follows. > > > > list_eg ::= single_packet_format, > { > ... > order_flag ::= control_field, > { > base_field ::= same_as(list_eg.list_of_fields.order_flag), > compressed_method ::= irregular(1) > }, > > presence_flag ::= control_field, > { > base_field ::= same_as > (list_eg.list_of_fields.presence_flag), > compressed_method ::= irregular(1) > }, > > list_of_fields ::= list_of_known_length, > { > list_length ::= constant(8), > order_flag ::= from_list(list_eg.order_flag), > presence_flag ::= from_list(list_eg.presence_flag), > ... > } > } > > >This seems to be a circular definition. For example, list_eg.order_flag is >same_as(list_eg.list_of_fields.order_flag), while >list_eg.list_of_fields.order_flag is from_list(list_eg.order_flag). Could >anyone please explain it to me? Have I misunderstood anything here? > >Thank you very much. >Haipeng > > > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun Nov 9 13:16:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05324 for ; Sun, 9 Nov 2003 13:16:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu6X-0004zC-1H for rohc-archive@odin.ietf.org; Sun, 09 Nov 2003 13:16:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9IG5Um019160 for rohc-archive@odin.ietf.org; Sun, 9 Nov 2003 13:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu6W-0004yx-UC for rohc-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05309 for ; Sun, 9 Nov 2003 13:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu6U-0004s1-00 for rohc-web-archive@ietf.org; Sun, 09 Nov 2003 13:16:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu6U-0004rx-00 for rohc-web-archive@ietf.org; Sun, 09 Nov 2003 13:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu6T-0004yf-Ay; Sun, 09 Nov 2003 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu6N-0004yE-0h for rohc@optimus.ietf.org; Sun, 09 Nov 2003 13:15:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05304 for ; Sun, 9 Nov 2003 13:15:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu6K-0004ru-00 for rohc@ietf.org; Sun, 09 Nov 2003 13:15:52 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AIu6J-0004rr-00 for rohc@ietf.org; Sun, 09 Nov 2003 13:15:52 -0500 Received: from dyn130-241.ietf58.ietf.org (dyn130-241.ietf58.ietf.org [130.129.130.241]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with ESMTP id hA9IFrKg024592; Sun, 9 Nov 2003 12:15:53 -0600 (CST) Date: Sun, 09 Nov 2003 19:17:17 +0100 From: Juergen Quittek To: "C. M. Heard" cc: ROHC mailing list , "Wijnen, Bert (Bert)" Subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Message-ID: <2147483647.1068405437@dyn130-241.ietf58.ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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 Mike, Thanks again for your careful check and the very good comments. Please see replies inline: --On 31.10.2003 0:15 h -0800 C. M. Heard wrote: > On Tue, 21 Oct 2003, Juergen Quittek wrote: >> > Below please find the detailed responses on all of your comments >> > with two exceptions: >> > >> > - 4.) IPR Notices >> > We are still checking the patent issues. >> > We will post the results on the mailing list >> > (with CC to you and Bert). >> >> Together with Lars-Erik, we checked the IPR issues. >> They do not apply to the MIB or to MIB implementations. > > OK > >> > - 11.) (e) ordering of the index components >> > This is discussed in a separate email thread on the list. >> >> We had long discussions on this issue. So far indexing has looked like: > [ ... details snipped, but each table used ifIndex ... ] >> We want to change this such that the rohcChannelID becomes unique >> for a ROHC MIB implementation independent of the interface or >> instance to which the channel belongs. >> >> This simplifies the profile table, all context tables and the >> RTP packet size table: >> >> rohcProfileTable: rohcChannelID, rohcProfile >> rohcContextTable: rohcChannelID, rohcContextCID >> rohcUncmprContextTable: rohcChannelID, rohcContextCID >> rohcRtpContextTable: rohcChannelID, rohcContextCID >> rohcRtpPacketSizeTable: rohcChannelID, rohcContextCID, rohcRtpPacketSize >> >> For the rohc channel table we still want to keep the old indexing >> scheme, because we believe it is useful to be able to access channels >> per interface and to access Instances by the rohc InstanceType: >> >> rohcChannelTable: ifIndex, rohcChannelID >> rohcInstanceTable: ifIndex, rohcInstanceType, rohcChannelID >> >> Addressing a good suggestion from Abbie >> >> >>>>> On Tue, 8 Jul 2003, Surtees, Abigail wrote: >> Abbie> However, looking at it from a MIB point of view I think >> Abbie> it is confusing to have a seemingly redundant index. >> Abbie> >> Abbie> Hence, I suggest that rohcInstanceType continues to be >> Abbie> an index but that there is some text added to the draft >> Abbie> explaining why it is there and that if you want to >> Abbie> uniquely identify one rohc instance (whether compressor >> Abbie> or decompressor) then ifIndex and rohcChannelID are >> Abbie> sufficient to do this. >> >> we suggest to modify the DESCRIPTION clauses [ ... details snipped ... ] >> >> A consequence of these changes would be that modules >> ROHC-UNCMPRESSED-MIB and ROHC-RTP-MIB do not use anymore the object >> ifIndex (or other objects from the IF-MIB and the IF-MIB can be >> removed from the IMPORT clause and the DESCRIPTION clause of the >> compliance statements. > > Allow me to point out that all three MIB modules have counters > and that each counter points to ifCounterDiscontinuityTime as > its discontinuity indicator. So it seems to me that there are > two problems here: > > - there is still a dependence on the IF-MIB OK. I will fix this in the conformance section after we got feedback from the IESG. > - the absence of ifIndex from the index list makes it hard for > a management application to find out which counters have > sufferred a discontinuity when an instance if ifConcerDiscontinuityTime > changes. > > So, I think you would be better off to re-instate ifIndex to the > INDEX clauses and mention of IF-MIB in the compliance statements. I'm hesitating to go back. After many discussions, I am convinced that we found a well balanced compromise. The management application can read the rohcChannelTable (that is still indexed by the ifIndex) and find a list of all channels that are affected with their respective rohcChannelId. Then it can use the rohcChannelId as index of all counters in other tables, which suffered from discontinuity. > Another point that I noticed is that the OID assignments for the > columnar objects are not contiguous, doubtless as a result of > removing columns from the tables. Here is the result of a quick > grep: > ::= { rohcChannelEntry 2 } > ::= { rohcChannelEntry 3 } > ::= { rohcChannelEntry 4 } > ::= { rohcChannelEntry 5 } > ::= { rohcChannelEntry 13 } Yes, this needs to be fixed. > ::= { rohcInstanceEntry 2 } > ::= { rohcInstanceEntry 4 } And this also. > ::= { rohcInstanceEntry 5 } > ::= { rohcInstanceEntry 6 } > ::= { rohcInstanceEntry 7 } > ::= { rohcInstanceEntry 8 } > ::= { rohcInstanceEntry 9 } > ::= { rohcInstanceEntry 10 } > ::= { rohcInstanceEntry 11 } > ::= { rohcInstanceEntry 12 } > ::= { rohcInstanceEntry 13 } > ::= { rohcInstanceEntry 14 } > ::= { rohcInstanceEntry 15 } > ::= { rohcInstanceEntry 16 } > ::= { rohcInstanceEntry 17 } > ::= { rohcInstanceEntry 18 } > ::= { rohcInstanceEntry 19 } > ::= { rohcInstanceEntry 20 } > ::= { rohcProfileEntry 2 } > ::= { rohcProfileEntry 3 } > ::= { rohcProfileEntry 4 } > ::= { rohcProfileEntry 5 } > ::= { rohcProfileEntry 6 } > ::= { rohcContextEntry 2 } > ::= { rohcContextEntry 3 } > ::= { rohcContextEntry 4 } > ::= { rohcContextEntry 5 } > ::= { rohcContextEntry 6 } > ::= { rohcContextEntry 7 } > ::= { rohcContextEntry 8 } > ::= { rohcContextEntry 9 } > ::= { rohcContextEntry 10 } > ::= { rohcContextEntry 11 } > ::= { rohcContextEntry 12 } > ::= { rohcContextEntry 13 } > ::= { rohcContextEntry 14 } > ::= { rohcContextEntry 15 } > ::= { rohcContextEntry 16 } > ::= { rohcContextEntry 17 } > ::= { rohcContextEntry 18 } > ::= { rohcContextEntry 19 } > ::= { rohcContextEntry 20 } > ::= { rohcContextEntry 21 } > ::= { rohcContextEntry 22 } > ::= { rohcRtpContextEntry 3 } > ::= { rohcRtpContextEntry 4 } > ::= { rohcRtpContextEntry 5 } > ::= { rohcRtpContextEntry 6 } > ::= { rohcRtpContextEntry 7 } > ::= { rohcRtpContextEntry 8 } > ::= { rohcRtpContextEntry 9 } > ::= { rohcRtpContextEntry 10 } > ::= { rohcRtpContextEntry 11 } > ::= { rohcRtpContextEntry 12 } > ::= { rohcRtpContextEntry 13 } > ::= { rohcRtpContextEntry 14 } > ::= { rohcRtpContextEntry 15 } > ::= { rohcRtpContextEntry 16 } > ::= { rohcRtpContextEntry 17 } > ::= { rohcRtpPacketSizeEntry 3 } > ::= { rohcRtpPacketSizeEntry 4 } > ::= { rohcRtpPacketSizeEntry 5 } > ::= { rohcRtpPacketSizeEntry 6 } > ::= { rohcUncmprContextEntry 3 } > ::= { rohcUncmprContextEntry 4 } > ::= { rohcUncmprContextEntry 5 } > > You may want to consider fixing this if you decide to > re-spin the MIB before publication. Certainly. If we just change the compliancy statements and the OID numbering, we can fix this at any stage in the document process until the 48 hours review by the authors. If we change the indexing again, we might have to discuss it with more people. > Regards, > > Mike Thanks, Juergen _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Nov 10 11:43:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29117 for ; Mon, 10 Nov 2003 11:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF83-0008KW-5D for rohc-archive@odin.ietf.org; Mon, 10 Nov 2003 11:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGh32n032019 for rohc-archive@odin.ietf.org; Mon, 10 Nov 2003 11:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF82-0008KL-WF for rohc-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29091 for ; Mon, 10 Nov 2003 11:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJF81-0007ew-00 for rohc-web-archive@ietf.org; Mon, 10 Nov 2003 11:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJF81-0007er-00 for rohc-web-archive@ietf.org; Mon, 10 Nov 2003 11:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF81-0008Jq-M7; Mon, 10 Nov 2003 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF7i-0008Ij-Nc for rohc@optimus.ietf.org; Mon, 10 Nov 2003 11:42:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29054 for ; Mon, 10 Nov 2003 11:42:29 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJF7h-0007eJ-00 for rohc@ietf.org; Mon, 10 Nov 2003 11:42:41 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJF7g-0007eG-00 for rohc@ietf.org; Mon, 10 Nov 2003 11:42:40 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAGgcJ07727 for ; Mon, 10 Nov 2003 18:42:38 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 18:42:37 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 10:42:33 -0600 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] Questions about SigComp over SIP X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 10 Nov 2003 11:42:30 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8B5@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Questions about SigComp over SIP Thread-Index: AcOkeE9xduWQXFmnQUOU+Inx8Ch4EgDLdOhA To: , X-OriginalArrivalTime: 10 Nov 2003 16:42:33.0258 (UTC) FILETIME=[A399C0A0:01C3A7A9] 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 John, Just to be accurate, the email subject would be better to read "SIP over SigComp". Please see comments in line. BR, Zhigang > 1. Quoting from RFC3486 (Compressing the Session=20 > Initiation Protocol): "The=20 > presence of this parameter (comp=3Dsigcomp) in a URI indicates that = the=20 > request has to be compressed using SigComp, as defined in=20 > [2]" (section no.=20 > 2). > Then, below in section no.7 it continues with: "If a SIP=20 > client sends a=20 > compressed request and the client transaction times out=20 > without having=20 > received any response, the client SHOULD retry the same=20 > request without=20 > using compression." This quotation instructs us to send the=20 > same message=20 > without specifying the following details: > =B7 Is the parameter 'comp=3Dsigcomp' has to be removed from=20 > the original=20 > request URI before re-sending the uncompressed SIP request message? My understanding of RFC3486 (if correct) is that it's not needed. The parameter "comp=3Dsigcomp" is mainly to indicate the *receiver's*=20 support of SigComp, not a mandate for a sender to send it. See quoted text from section 2 below. (I agree the "hast to" wording mentioned = above is confusing. I don't know how it ended up there.) Therefore, the presence of comp=3Dsigcomp indicates that the SIP = entity identified by the URI or by the Via header field supports SigComp and is willing to receive compressed messages. Having comp=3Dsigcomp = mean "willingness" as well as "support" allows the receiver of a SIP message to influence the decision of whether or not to use SigComp at a given time. > =B7 In case that a SIP message has to be re-sent=20 > uncompressed, should it=20 > contain different Via branch value (as it is done after transmission=20 > failure, when using DNS) or different CSeq? The values should be set according to SIP, regardless whether or not SigComp is used. SigComp is just a transport. > 2. Is there any example of SigComp state that is created=20 > dynamically and is=20 > used by more than a single compartment? I'm looking for an=20 > example of state=20 > that is not 'global' or created during initialization process=20 > (such as state=20 > that keeps the dictionary or state that keeps=20 > compression/decompression=20 > algorithm). I don't have one from the top of my head.=20 =20 > 3. Do the compression/decompression algorithms instruct us=20 > which states and=20 > how many of them have to be created in order to support the=20 > SigComp feature?=20 > or Does the states creation depend on the way that SigComp is=20 > implemented? Those depend on the compressor (sender). SigComp essentially=20 specifies the expected behaviour/constraints of the decompressor (receiver). It's up to the compressor implementation on how to use the SigComp framework and drive the operations. Think about Java VM and applet.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Nov 10 12:00:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00245 for ; Mon, 10 Nov 2003 12:00:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFOb-00012H-KV for rohc-archive@odin.ietf.org; Mon, 10 Nov 2003 12:00:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAH09NK003973 for rohc-archive@odin.ietf.org; Mon, 10 Nov 2003 12:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFOZ-00011o-58 for rohc-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 12:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00163 for ; Mon, 10 Nov 2003 11:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFOX-0000Ec-00 for rohc-web-archive@ietf.org; Mon, 10 Nov 2003 12:00:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFOW-0000EY-00 for rohc-web-archive@ietf.org; Mon, 10 Nov 2003 12:00:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFOU-000117-Nd; Mon, 10 Nov 2003 12:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFO5-0000zK-7K for rohc@optimus.ietf.org; Mon, 10 Nov 2003 11:59:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00098 for ; Mon, 10 Nov 2003 11:59:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFO3-0000DT-00 for rohc@ietf.org; Mon, 10 Nov 2003 11:59:36 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AJFO3-0000Cs-00 for rohc@ietf.org; Mon, 10 Nov 2003 11:59:35 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Nov 2003 16:59:03 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPPKB; Mon, 10 Nov 2003 16:58:59 -0000 From: "West, Mark" To: zhigang.c.liu@nokia.com Cc: johnyjsmith1970@hotmail.com, rohc@ietf.org Date: Mon, 10 Nov 2003 16:58:53 +0000 (GMT Standard Time) Subject: RE: [rohc] Questions about SigComp over SIP In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B808E8B5@ajebe001.americas.nokia.com> Message-ID: References: <7B5AF06E216CB74DA8A5960A3181B5B808E8B5@ajebe001.americas.nokia.com> X-X-Sender: maw1@maw-laptop.roke.co.uk 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: , Hi John, Zhigang, A very small additional comment to one of Zhigang's answers... > > 2. Is there any example of SigComp state that is created > > dynamically and is > > used by more than a single compartment? I'm looking for an > > example of state > > that is not 'global' or created during initialization process > > (such as state > > that keeps the dictionary or state that keeps > > compression/decompression > > algorithm). > > I don't have one from the top of my head. Well, isn't the bytecode an example of this? It depends what you mean by 'initialisation', but the bytecode is not 'universal'. Whereas, the 'static dictionary' is, I would imagine, always present -- it's hard to imagine the dictionary (for example) being *sent* by an endpoint... (I can only really see it being use if its presence is advertised / mandated for the particular environment). In any case, it's not really clear why it's important to have an example... it can happen and is explicitly supported in the definition of state management in RFC 3320. So an implementation has to handle it, even if you don't think that it's going to occur very often... Cheers, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 11 09:41:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02493 for ; Tue, 11 Nov 2003 09:41:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZhY-0004a3-8t for rohc-archive@odin.ietf.org; Tue, 11 Nov 2003 09:41:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABEf47N017603 for rohc-archive@odin.ietf.org; Tue, 11 Nov 2003 09:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZhY-0004Zq-5A for rohc-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 09:41:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02483 for ; Tue, 11 Nov 2003 09:40:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZhW-0003qr-00 for rohc-web-archive@ietf.org; Tue, 11 Nov 2003 09:41:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJZhV-0003qn-00 for rohc-web-archive@ietf.org; Tue, 11 Nov 2003 09:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZhV-0004ZX-CA; Tue, 11 Nov 2003 09:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZgl-0004YY-Gu for rohc@optimus.ietf.org; Tue, 11 Nov 2003 09:40:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02448 for ; Tue, 11 Nov 2003 09:40:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZgj-0003qB-00 for rohc@ietf.org; Tue, 11 Nov 2003 09:40:13 -0500 Received: from law15-f47.law15.hotmail.com ([64.4.23.47] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AJZgi-0003pc-00 for rohc@ietf.org; Tue, 11 Nov 2003 09:40:13 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Nov 2003 06:39:41 -0800 Received: from 62.254.246.40 by lw15fd.law15.hotmail.msn.com with HTTP; Tue, 11 Nov 2003 14:39:40 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] From: "Richard Price" To: rohc@ietf.org Subject: Re: [rohc] RE: Question about ROHC FN Date: Tue, 11 Nov 2003 14:39:40 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2003 14:39:41.0137 (UTC) FILETIME=[A3E31C10:01C3A861] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Haipeng, The "uncompressible" encoding method is something of an anachronism. We included it as a quick hack for handling variable-length uncompressible fields, way back in the very first version of the formal notation, and it has somehow managed to survive unchanged ever since. As your email makes clear, trying to use the "uncompressible" encoding method can result in a serious headache. The source of the confusion is the large selection of mysterious parameters that follow the encoding method - it's difficult to remember what the parameters are for, and the order in which they're supposed to occur. In more recent versions of the formal notation, we've tried to reduce the reliance on magic numbers by converting the potentially confusing parameters into proper, named fields in their own right. We could easily do this for the uncompressible encoding method as well, e.g: foo ::= uncompressible { base_length ::= same_as(some_other_field) multiplier ::= 8 divisor ::= 1 offset ::= 16 } Even better, why not put the expression for deriving the length of the uncompressible field straight into the formal notation? This would look something like: foo ::= uncompressible { field_length ::= expression(uncomp(some_other_field) * 8 + 16) } Either of the above would help to avoid confusion about what the parameters following the "uncompressible" encoding method are actually for. Regards, Richard Price P.S. Regarding the specific points raised below, I think that the example in the ROHC-FN draft is correct - the length of the uncompressible data is intended to be: (uncomp(test_uncompressible.length)/2)*2 + 4 However, the use of "uncompressible" encoding in the TCP profile is wrong - the parameters for the multiplier and the divisor are the wrong way round. Giving each parameter an explicit name would help to avoid this ;-) >>---------- >>From: Haipeng Jin[SMTP:HAIPENGJ@QUALCOMM.COM] >>Sent: Friday, November 07, 2003 6:25:58 PM >>To: Finking, Robert; 'rohc@ietf.org' >>Subject: Re: [rohc] RE: Question about ROHC FN >>Auto forwarded by a Rule >> >Robert, > >Thank you for your explanation, that is very clear. > >I have another question about the encoding method "uncompressible". > >In ROHC FN 5.5.1, the example shows > > > test_uncompressible ::= single_packet_format, > { > uncompressed_data ::= length, > data, > > compressed_data ::= data, > > length ::= value(4, 1), > > data ::= uncompressible > (test_uncompressible.length, 2, 2, 4) > } > > >I am wondering whether it actually should be > > data ::= uncompressible (test_uncompressible.length, 2, 2, -4). > >The uncompressible size of data should be >(uncomp(test_uncompressible.length)/2)*2 - 4 instead of >(uncomp(test_uncompressible.length)/2)*2 + 4, right? > >Also since you are mentioning ROHC-TCP, there seems to be an inconsistent >in using "uncompressible" in the ROHC FN draft and ROHC TCP draft. Again, >ROHC FN 5.5.1 says > > > The encoding method takes four parameters. The first parameter gives > the base value for calculating the length of the data, whilst the > next three parameters specify a divisor, multiplier and offset which > scale the variable so that it specifies the size of the > uncompressible field in bits. > >So the uncompressible method is defined as uncompressible (base, divisor, >multiplier, offset). While in ROHC-TCP 6.5.3, the generic format for >compressing TCP option is given as: > > generic ::= single_packet_format, > > { uncompressed_data ::= kind, % 8 bits > length, % 8 bits > data_item, % data_size bits > > compressed_data ::= data_item, > > kind ::= static, > length ::= static, > data_item ::= > uncompressible(tcp_ip.tcp_options.generic.length, 8, 1, -16) > } > } > } > }. > >If we use the definition for uncompressible in ROHC-FN, the data_item size >will be (tcp_ip.tcp_options.generic.length)/8 - 16, but the actual size in >bits should be (tcp_ip. ... .length)*8 - 16. Right? > >Thanks, > >Haipeng _________________________________________________________________ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 11 12:31:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11915 for ; Tue, 11 Nov 2003 12:31:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcLm-0004F6-0v for rohc-archive@odin.ietf.org; Tue, 11 Nov 2003 12:30:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHUkhQ016308 for rohc-archive@odin.ietf.org; Tue, 11 Nov 2003 12:30:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcLl-0004Ex-UZ for rohc-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:30:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11856 for ; Tue, 11 Nov 2003 12:30:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcLk-0006gh-00 for rohc-web-archive@ietf.org; Tue, 11 Nov 2003 12:30:44 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AJcHs-0006Xa-03 for rohc-web-archive@ietf.org; Tue, 11 Nov 2003 12:26:45 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AJc0l-0006gl-6r for rohc-web-archive@ietf.org; Tue, 11 Nov 2003 12:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc0j-00029o-6T; Tue, 11 Nov 2003 12:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbzt-00023d-1Z for rohc@optimus.ietf.org; Tue, 11 Nov 2003 12:08:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10456 for ; Tue, 11 Nov 2003 12:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbzr-0006FG-00 for rohc@ietf.org; Tue, 11 Nov 2003 12:08:07 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AJbzq-0006FC-00 for rohc@ietf.org; Tue, 11 Nov 2003 12:08:07 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hABH81I2015593 for ; Tue, 11 Nov 2003 18:08:01 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 18:08:01 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: rohc@ietf.org Date: Tue, 11 Nov 2003 18:07:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [rohc] ROHC TCP requirements, compression if IPv4 Options are present? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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 While reviewing the ROHC TCP requirements, we have found that it suggests compression should work also with IPv4 Options. We believe this requirement does not really make sense, and suggest to replace the current text: "2.2. Supported Headers and Kinds of TCP Streams 1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all possible changes in the IP header fields must be handled by the compression scheme, and commonly changing fields should be compressed efficiently. Compression must not be disabled if IPv4 Options or IPv6 Extensions are present. The compression scheme must further consider as normal operation the scenario where Explicit Congestion Notification (ECN) [RFC-3168] is applied and support efficient compression also in the case when the ECN bits are used." With: "2.2. Supported Headers and Kinds of TCP Streams 1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all possible changes in the IP header fields must be handled by the compression scheme, and commonly changing fields should be compressed efficiently. Compression must not be disabled if IPv6 Extensions are present. The compression scheme must further consider as normal operation the scenario where Explicit Congestion Notification (ECN) [RFC-3168] is applied, and support = efficient compression also in the case when the ECN bits are = used. /Lars-Erik et al. ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 12 16:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10485 for ; Wed, 12 Nov 2003 16:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2W0-00080Q-Fu for rohc-archive@odin.ietf.org; Wed, 12 Nov 2003 16:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLR4p1030770 for rohc-archive@odin.ietf.org; Wed, 12 Nov 2003 16:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2W0-00080D-BL for rohc-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10457 for ; Wed, 12 Nov 2003 16:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Vy-0006fR-00 for rohc-web-archive@ietf.org; Wed, 12 Nov 2003 16:27:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK2Vx-0006fN-00 for rohc-web-archive@ietf.org; Wed, 12 Nov 2003 16:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Vx-0007zn-LD; Wed, 12 Nov 2003 16:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2V1-0007xt-5n for rohc@optimus.ietf.org; Wed, 12 Nov 2003 16:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10403 for ; Wed, 12 Nov 2003 16:25:50 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Uy-0006dz-00 for rohc@ietf.org; Wed, 12 Nov 2003 16:26:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Ux-0006dt-00 for rohc@ietf.org; Wed, 12 Nov 2003 16:26:00 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACLPwA28292 for ; Wed, 12 Nov 2003 23:25:58 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Nov 2003 23:25:56 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 15:25:28 -0600 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] Old issue - multiplexing compressed and uncompressed messages in the same TCP connection - long X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 12 Nov 2003 16:25:26 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8BF@ajebe001.americas.nokia.com> Thread-Topic: Old issue (draft-ietf-rohc-sigcomp-sip-00.txt) Thread-Index: AcOBzOJhSdl2dOv7QJWAuIgOKfShnQA/oQ3AABa7wnAASTGuYAItqSqgAFVg9lABlPPNwAUtgieQ To: , X-OriginalArrivalTime: 12 Nov 2003 21:25:28.0131 (UTC) FILETIME=[7E3D5130:01C3A963] 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 Hello All, Thanks for Robert to raise this old issue again. My personal=20 view has been that multiplexing is really good (and easy) to=20 have. Below Robert has given a good in-depth description of the reasons. I'd like also to hear opinions from other people, especially if they are different. Otherwise, I plan to update sigcomp-sip I-D accordingly. BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Robert.Sugar@nokia.com > Sent: October 20, 2003 03:18 AM > To: rohc@ietf.org > Subject: [rohc] Old issue - multiplexing compressed and uncompressed > messages in the same TCP connection - long >=20 >=20 > Hi all, >=20 > You probably remember that discussion over $subject. As far=20 > as I can remember, conclusion was that although it could be=20 > implemented with a common transport layer, there is really no=20 > need to add the extra complexity.=20 >=20 > RFC3486 has the following, reflecting that: > "If a SIP client sends a compressed request and the client=20 > transaction times out without having received any response,=20 > the client SHOULD retry the same request without using=20 > compression. If the compressed request was sent over a TCP=20 > connection, the client SHOULD close that connection and open=20 > a new one to send the uncompressed request. Otherwise the=20 > server would not be able to detect the beginning of the new message." >=20 > So, why do we need compressed and uncompressed messages=20 > multiplexed in the first place? >=20 > 1. Fallback to uncompressed mode (also suggested in RFC3486) > 2. Large messages: OUTPUT instruction stops after 64Kbytes of=20 > data, so SIP messages larger than 64K are to be sent=20 > uncomperssed. This is not an impossible case, since SIP=20 > messages may carry arbitrary MIME attachments, such as XML=20 > (->presence info), WAV (->ringing tone), JPG (-> caller's photo), etc. > 3. If there is no comp=3Dsigcomp URI to the proxy (proxy=20 > discovery usually yields only the IP address), initial=20 > messages are to be sent uncompressed, but subsequent messages=20 > could be sent compressed if comp=3Dsigcomp is inserted into the=20 > Record-Route by the proxy. If no comp=3Dsigcomp contact is=20 > given later, all initial requests will be sent uncompressed. > 4. RFC3486 allows inserting comp=3Dsigcomp into SIP headers=20 > anytime. Preference for insertion might be for example the=20 > load of the proxy. If there are parallel sessions in the same=20 > compartment, at least one compressed and one uncompressed,=20 > TCP connections should be closed and re-opened anytime=20 > messages interleave. This would cause unnecessary extra=20 > delays and roundtrips due to the TCP handshake. >=20 > Why is it hard to close and re-open the TCP connections? >=20 > Problem is that if we use lower-layer security, such as=20 > IPSec (as in 3GPP for one example), we cannot open and close=20 > ports at will, because security associations have fixed=20 > selectors (source IP, source port, destination IP,=20 > destination port, protocol). The only way we could open a new=20 > TCP connection is to use exactly the same 5 selectors as the=20 > original one. > According to TCP: "Another effect of this 2MSL wait is that=20 > while the TCP connection is in the 2MSL wait, the socket pair=20 > defining the connection (client IP address, client port=20 > number, server IP address, server port number) cannot be=20 > reused. That connection can only be reused when the 2MSl=20 > wait is over." > MSL is the maximum segment lifetime, which is by RFC=20 > recommendation 2 minutes, but many implementations use 30=20 > seconds. Effectively, it means that the connection cannot be=20 > reused for 1-4 minutes after closure. >=20 > How it could be implemented? >=20 > A possible implementation could be: > - Transport looks at the first byte of the message, and=20 > cheks whether it starts with 11111. > - If yes, the stream is passed to SigComp that reads it=20 > till 0xFFFF and returns > - If no, the stream is passed to SIP that reads it as=20 > long as indicated by Content-Length > - Rinse, Repeat >=20 > Of course if the Content-Length is improperly filled,=20 > missing or SigComp messages contain additional 0xFFFF or do=20 > not end with 0xFFFF, it might happen that a parser receives=20 > messages that are erroneous, partial or belong to the other=20 > protocol. In that case the next message or all messages=20 > inside that stream could be lost. But similar problems also=20 > arise in a stream containing SIP or SigComp messages only. >=20 > What do you think? >=20 > BR, > Robert >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 12 17:44:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13850 for ; Wed, 12 Nov 2003 17:44:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3ia-0005yU-Ft for rohc-archive@odin.ietf.org; Wed, 12 Nov 2003 17:44:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACMi8E6022959 for rohc-archive@odin.ietf.org; Wed, 12 Nov 2003 17:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3ia-0005yE-Bv for rohc-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 17:44:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13809 for ; Wed, 12 Nov 2003 17:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3iW-0000A8-00 for rohc-web-archive@ietf.org; Wed, 12 Nov 2003 17:44:04 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK3iV-00009c-01 for rohc-web-archive@ietf.org; Wed, 12 Nov 2003 17:44:03 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK3fc-0006vP-S6 for rohc-web-archive@ietf.org; Wed, 12 Nov 2003 17:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3fZ-0005mK-8v; Wed, 12 Nov 2003 17:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3ew-0005kw-5I for rohc@optimus.ietf.org; Wed, 12 Nov 2003 17:40:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13739 for ; Wed, 12 Nov 2003 17:40:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3et-00008c-00 for rohc@ietf.org; Wed, 12 Nov 2003 17:40:19 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AK3et-00008S-00 for rohc@ietf.org; Wed, 12 Nov 2003 17:40:19 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 22:39:49 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPSJX; Wed, 12 Nov 2003 22:39:48 -0000 From: "West, Mark" To: zhigang.c.liu@nokia.com Cc: Robert.Sugar@nokia.com, rohc@ietf.org Date: Wed, 12 Nov 2003 22:39:43 +0000 (GMT Standard Time) Subject: RE: [rohc] Old issue - multiplexing compressed and uncompressed messages in the same TCP connection - long In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B808E8BF@ajebe001.americas.nokia.com> Message-ID: References: <7B5AF06E216CB74DA8A5960A3181B5B808E8BF@ajebe001.americas.nokia.com> X-X-Sender: maw1@maw-laptop.roke.co.uk 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: , Hi all, I still go along with what I still believe was the majority view from S-F, which was: 'yeah, you could do this, but why would you want to..?' But first of all, can I be *really* pedantic about terminology..? We should differentiate between: - SigComp message; and - non-SigComp message With respect to the former, these can be compressed or uncompressed. (Further, the compression used can make use of states at the remote end-point, or be state-less). The main justification given for multiplexing sigcomp and non-sigcomp messages seems to be that it's too hard to re-open a new TCP connection. Now, there may be transport-friendliness issues with continually closing & opening TCP connections, but the idea of having a fixed rather than ephemeral source port seems slightly weird... not least because that seems to break recovery if you close a session on detection of wrong content-length, for example? I agree that there are many reasons for needing to be able to send a mix of SigComp & non-SigComp messages between 2 SIP peers. These are not necessarily reasons for multiplexing these messages on the same TCP flow, though. If you were allowed to have multiple TCP connections or to re-open a new connection easily, why would you want to do multiplexing on a single connection..? This implementation suggestion: > > A possible implementation could be: > > - Transport looks at the first byte of the message, and > > cheks whether it starts with 11111. > > - If yes, the stream is passed to SigComp that reads it > > till 0xFFFF and returns > > - If no, the stream is passed to SIP that reads it as > > long as indicated by Content-Length > > - Rinse, Repeat makes it sound easy, but the throw-away 'is passed to' seems to me to conceal all of the complexity / layering problems / tricky stuff... So, no, I don't like the idea of putting SigComp & non-SigComp messages on the same connection... ... but feel free to try and convince me otherwise..! Cheers, Mark. On Wed, 12 Nov 2003 zhigang.c.liu@nokia.com wrote: > Date: Wed, 12 Nov 2003 16:25:26 -0500 > From: zhigang.c.liu@nokia.com > To: Robert.Sugar@nokia.com, rohc@ietf.org > Subject: RE: [rohc] Old issue - multiplexing compressed and uncompressed > messages in the same TCP connection - long > > Hello All, > > Thanks for Robert to raise this old issue again. My personal > view has been that multiplexing is really good (and easy) to > have. Below Robert has given a good in-depth description of the > reasons. I'd like also to hear opinions from other people, > especially if they are different. Otherwise, I plan to update > sigcomp-sip I-D accordingly. > > BR, > Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 12 18:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18004 for ; Wed, 12 Nov 2003 18:51:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4lL-0003f9-7R for rohc-archive@odin.ietf.org; Wed, 12 Nov 2003 18:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACNp3Jh014073 for rohc-archive@odin.ietf.org; Wed, 12 Nov 2003 18:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4lL-0003eu-3O for rohc-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 18:51:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17982 for ; Wed, 12 Nov 2003 18:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4lH-0001JL-00 for rohc-web-archive@ietf.org; Wed, 12 Nov 2003 18:50:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK4lH-0001JI-00 for rohc-web-archive@ietf.org; Wed, 12 Nov 2003 18:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4lK-0003ed-4E; Wed, 12 Nov 2003 18:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4ku-0003YF-AO for rohc@optimus.ietf.org; Wed, 12 Nov 2003 18:50:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17968 for ; Wed, 12 Nov 2003 18:50:21 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4kr-0001Iv-00 for rohc@ietf.org; Wed, 12 Nov 2003 18:50:33 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK4kq-0001Is-00 for rohc@ietf.org; Wed, 12 Nov 2003 18:50:32 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACNoWA13956 for ; Thu, 13 Nov 2003 01:50:32 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 01:50:32 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 15:50:29 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: multiplexing SigComp and non-SigComp messages on the same TCP connection (was RE: [rohc] Old issue - multiplexing compressed and uncompressed messages in the same TCP connection - long) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 12 Nov 2003 18:50:28 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8C3@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Old issue - multiplexing compressed and uncompressed messages in the same TCP connection - long Thread-Index: AcOpbecXtdiKJMpEQi6++fUYkH+3/wAA4rxQ To: Cc: , X-OriginalArrivalTime: 12 Nov 2003 23:50:29.0679 (UTC) FILETIME=[C0C42BF0:01C3A977] 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 Mark, I'm glad that my "threat" in my last sentence achieved its purpose. :-) And thanks for the commetns. I feel discussions are really needed to=20 clear this subject. Please see my comments in line. Zhigang > But first of all, can I be *really* pedantic about terminology..? We > should differentiate between: > - SigComp message; and > - non-SigComp message You're absolutely right. I was too busy to correct this, but this is important. I changed the subject line to reflect this. > If you were allowed to have multiple TCP connections or to=20 > re-open a new connection easily, why would you want to do=20 > multiplexing on a single connection..? This is the key question. Actually that is one of the questions=20 I've asked Robert during our offline discussion. The answers were=20 (if I understood correctly): - Re-opening a new TCP connection means extra delay. I tend to agree, since the establishment and tear-down of a TCP connection=20 require quite some procedures in the state machine.=20 - In certain cases, we are not allowed to have multiple TCP connections. I learned that this is the case for 3GPP, in particular, due to security policy as Robert described earlier. However, it is unclear to me if it is simply a bad choice made by 3GPP, or it is due to some=20 technical reasons that are more generic than 3GPP. This is something I would like to figure out during this discussion. > This implementation suggestion: >=20 > > > A possible implementation could be: > > > - Transport looks at the first byte of the message, and > > > cheks whether it starts with 11111. > > > - If yes, the stream is passed to SigComp that reads it > > > till 0xFFFF and returns > > > - If no, the stream is passed to SIP that reads it as > > > long as indicated by Content-Length > > > - Rinse, Repeat >=20 > makes it sound easy, but the throw-away 'is passed to' seems to me to > conceal all of the complexity / layering problems / tricky stuff... I do agree this doesn't look nice in the layering diagram. However, I don't think it is complex or tricky to implement. SigComp already=20 requires quite interactions with SIP layer anyway. Or, perhaps I missed something here? _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 13 08:59:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26801 for ; Thu, 13 Nov 2003 08:59:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHzy-0003E7-6B for rohc-archive@odin.ietf.org; Thu, 13 Nov 2003 08:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADDx2OJ012397 for rohc-archive@odin.ietf.org; Thu, 13 Nov 2003 08:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHzy-0003Ds-2X for rohc-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 08:59:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26784 for ; Thu, 13 Nov 2003 08:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKHzw-00057X-00 for rohc-web-archive@ietf.org; Thu, 13 Nov 2003 08:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKHzw-00057U-00 for rohc-web-archive@ietf.org; Thu, 13 Nov 2003 08:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHzw-0003Dc-Oo; Thu, 13 Nov 2003 08:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHz3-0003D6-Jv for rohc@optimus.ietf.org; Thu, 13 Nov 2003 08:58:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26758 for ; Thu, 13 Nov 2003 08:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKHz1-00057P-00 for rohc@ietf.org; Thu, 13 Nov 2003 08:58:04 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AKHz1-00057H-00 for rohc@ietf.org; Thu, 13 Nov 2003 08:58:03 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Nov 2003 13:57:31 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPS91; Thu, 13 Nov 2003 13:57:29 -0000 From: "West, Mark" To: zhigang.c.liu@nokia.com Cc: Robert.Sugar@nokia.com, rohc@ietf.org Date: Thu, 13 Nov 2003 13:57:24 +0000 (GMT Standard Time) In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B808E8C3@ajebe001.americas.nokia.com> Message-ID: References: <7B5AF06E216CB74DA8A5960A3181B5B808E8C3@ajebe001.americas.nokia.com> X-X-Sender: maw1@maw-laptop.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] Re: multiplexing SigComp and non-SigComp messages on the same TCP connection Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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 Zhigang, I agree -- you can't beat a good threat... ;-) Comments, as ever, in-line. Cheers, Mark. > > If you were allowed to have multiple TCP connections or to > > re-open a new connection easily, why would you want to do > > multiplexing on a single connection..? > > This is the key question. Actually that is one of the questions > I've asked Robert during our offline discussion. The answers were > (if I understood correctly): > > - Re-opening a new TCP connection means extra delay. I tend > to agree, since the establishment and tear-down of a TCP connection > require quite some procedures in the state machine. > This is true: there's a 3-way handshake to establish a new TCP connection. I'm not sure how much of a big deal this is, since most of the conditions for sending a non-SigComp message involve significant latency (retransmission; message > 64kbyte; ...) However, from my reading of RFC 3261 (I am not now, nor have ever claimed to be any kind of SIP expert; so if anyone wishes to correct this, feel free..!) you could have a SigComp & non-SigComp TCP connection open... > - In certain cases, we are not allowed to have multiple TCP connections. > I learned that this is the case for 3GPP, in particular, due to security > policy as Robert described earlier. However, it is unclear to > me if it is simply a bad choice made by 3GPP, or it is due to some > technical reasons that are more generic than 3GPP. This is something > I would like to figure out during this discussion. > My personal opinion is that this security model is broken. It is usual to have ephemeral source ports and I can't see how it helps to nail down the source port. RFC 3261 section 18 says that the source port is 'often ephemeral'. Moreoever, 3261 describes having a 'dwell time' for a connection to allow a transaction to complete within a single connection. After this time, the connection is/can be closed. The 'fixed port' model means that you can't re-open a connection within the time-wait time... ... also all the text in section 18 about error conditions and re-opening connections seems to be rendered unusable in this scenario... > > This implementation suggestion: > > > > > > A possible implementation could be: > > > > - Transport looks at the first byte of the message, and > > > > cheks whether it starts with 11111. > > > > - If yes, the stream is passed to SigComp that reads it > > > > till 0xFFFF and returns > > > > - If no, the stream is passed to SIP that reads it as > > > > long as indicated by Content-Length > > > > - Rinse, Repeat > > > > makes it sound easy, but the throw-away 'is passed to' seems to me to > > conceal all of the complexity / layering problems / tricky stuff... > > I do agree this doesn't look nice in the layering diagram. However, > I don't think it is complex or tricky to implement. SigComp already > requires quite interactions with SIP layer anyway. Or, perhaps I > missed something here? > I agree that there are significant interactions between SIP and SigComp. However, these are all defined in RFC 3320. The point is that SigComp should (from a transport perspective) be able to look (mostly) like an alternative transport for SIP. Multiplexing really breaks that model. I think my point is that *not* allowing multiplexing means that you can separate the implementation details. (You don't have to if you don't want to, but you *can*). If you insist on allowing multiplexing, then a receiving endpoint *must* support it, and that's going to put a bunch of constraints and requirements on the implementation. I don't think that those constraints need to be there, and so I'd prefer not to have them... _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 13 10:18:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02125 for ; Thu, 13 Nov 2003 10:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJEQ-0001jU-PC for rohc-archive@odin.ietf.org; Thu, 13 Nov 2003 10:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFI2QR006659 for rohc-archive@odin.ietf.org; Thu, 13 Nov 2003 10:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJEQ-0001jG-Gj for rohc-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:18:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02072 for ; Thu, 13 Nov 2003 10:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJEN-0006h3-00 for rohc-web-archive@ietf.org; Thu, 13 Nov 2003 10:18:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJEN-0006h0-00 for rohc-web-archive@ietf.org; Thu, 13 Nov 2003 10:17:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJEO-0001ij-VI; Thu, 13 Nov 2003 10:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJE1-0001eD-D5 for rohc@optimus.ietf.org; Thu, 13 Nov 2003 10:17:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01992 for ; Thu, 13 Nov 2003 10:17:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJDz-0006gD-00 for rohc@ietf.org; Thu, 13 Nov 2003 10:17:35 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKJDw-0006g8-00 for rohc@ietf.org; Thu, 13 Nov 2003 10:17:33 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hADFHQEf023748; Thu, 13 Nov 2003 16:17:27 +0100 (MET) Date: Thu, 13 Nov 2003 16:17:32 +0100 Subject: Re: [rohc] sigcomp-sip status Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann To: From: Carsten Bormann In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B808DC76@ajebe001.americas.nokia.com> Message-Id: <81112C31-15EC-11D8-90E6-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 Here is a braindump of a breakfast meeting Mark and I just had. All great ideas are Mark's, all errors are mine... Please excuse the terseness, this is mainly to preserve the many threads we had. Gruesse, Carsten 2003-11-13 Mark West/cabo Re sigcomp-sip draft: 8 K DMS is a no-brainer 2 K SMS means -- can't compress to stateless proxies (i.e., "really stateless" proxies can't advertise sigcomp) 0 K SMS means -- can't establish state in initial message and rely on it -- can still assume it's there -- need to wait for ACK to find out for real Mark will find a number for what 0 K SMS "costs". Multiplexing: Please use minimal UDVM programs (INPUT-BYTE, OUTPUT, JUMP) to carry uncompressed messages in SigComp streams. This is seven bytes plus a four-byte SigComp header. Compartment: For INVITE/dialogs, the draft seems fine (but see below). Note that, when a dialog ends, state may need to be kept around for the odd retransmission (cf. TIME_WAIT). Re: Maintaining state across dialogs: I propose to create a new SIP header like: SigComp-State-Promise: 1230402134098913284a729f 20h (or absolute time, but relative seems more conservative -- implementations will need to compensate for RTTs and some time skew) As with any state promise, this is just an optimization, so need not be reliable. REGISTER transactions? There is no dialog to attach the compartment to. BTW. It would be nice to be able to keep user state (e.g., for a re-register) for the duration of the registration. What other pieces of state (in addition to dialog and registration) are there that we may want to attach a compartment to? The transaction/dialog dilemma could be solved by installing the compartment for a transaction and later binding that to a dialog. Some implementations may not even know the compartment at 100 Trying time, so state installation may have to wait for 180 Ringing. This would require the state to remain in limbo until SIP stack is ready to acknowledge, which is what we are trying to minimize. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 05:19:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04764 for ; Fri, 14 Nov 2003 05:19:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKb2n-0003Li-U1 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 05:19:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEAJD1C012842 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 05:19:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKb2l-0003Kq-Hf for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 05:19:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04756 for ; Fri, 14 Nov 2003 05:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKb2h-0002dK-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 05:19:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKb2h-0002dG-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 05:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKb2h-0003JP-BO; Fri, 14 Nov 2003 05:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKb1y-0003IO-7G for rohc@optimus.ietf.org; Fri, 14 Nov 2003 05:18:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04735 for ; Fri, 14 Nov 2003 05:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKb1u-0002co-00 for rohc@ietf.org; Fri, 14 Nov 2003 05:18:18 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AKb1u-0002cl-00 for rohc@ietf.org; Fri, 14 Nov 2003 05:18:18 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAEAIII2015744; Fri, 14 Nov 2003 11:18:18 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Nov 2003 11:18:17 +0100 Message-ID: From: "Jan Christoffersson (LU/EAB)" To: zhigang.c.liu@nokia.com, "'West, Mark'" , Robert.Sugar@nokia.com, rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Fri, 14 Nov 2003 11:17:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, it seems to be different opinions on how to handle SigComp and SIP over TCP. I think that multiplexing over the same TCP connection is a good idea. Of course, there can be situations where it is not wanted, but then, there is nothing stopping you from opening a separate connection. To me, the main arguments for allowing multiplexing over the same TCP connection are 1. The extra delay caused by opening and closing TCP connections when switching between SIP and SigComp should not be neglected. In some cases it may be of little concern but in others it may be important. Reducing delay has been the most important driving factor for SigComp. Multiplexing over the same connection reduces the delay. 2. We have the tools needed for multiplexing SigComp and SIP on the same TCP connection. Why not do it? It's faster than opening a new connection. 3. Mark argues that if multiplexing is allowed, the receiver needs to support it. But doesn't it already need to do this? As Zhigang pointed out, RFC3486 states that "If a SIP client sends a compressed request and the client transaction times out without having received any response, the client SHOULD retry the same request without using compression. If the compressed request was sent over a TCP connection, the client SHOULD close that connection and open a new one to send the uncompressed request." In this text, it says SHOULD and not MUST, i.e. there could be implementations that send SIP and SigComp on the same TCP connection, so all implementations should be able to handle it. In any case, we have delimiters to determine where SigComp messages start and end, and if there is something other than SigComp in between an end and a start, we should be able to handle it. I feel that we should allow multiplexing of SigComp and SIP on the same TCP connection. Best Regards Jan -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of West, Mark Sent: den 13 november 2003 14:57 To: zhigang.c.liu@nokia.com Cc: Robert.Sugar@nokia.com; rohc@ietf.org Subject: [rohc] Re: multiplexing SigComp and non-SigComp messages on the same TCP connection Hi Zhigang, I agree -- you can't beat a good threat... ;-) Comments, as ever, in-line. Cheers, Mark. > > If you were allowed to have multiple TCP connections or to > > re-open a new connection easily, why would you want to do > > multiplexing on a single connection..? > > This is the key question. Actually that is one of the questions > I've asked Robert during our offline discussion. The answers were > (if I understood correctly): > > - Re-opening a new TCP connection means extra delay. I tend > to agree, since the establishment and tear-down of a TCP connection > require quite some procedures in the state machine. > This is true: there's a 3-way handshake to establish a new TCP connection. I'm not sure how much of a big deal this is, since most of the conditions for sending a non-SigComp message involve significant latency (retransmission; message > 64kbyte; ...) However, from my reading of RFC 3261 (I am not now, nor have ever claimed to be any kind of SIP expert; so if anyone wishes to correct this, feel free..!) you could have a SigComp & non-SigComp TCP connection open... > - In certain cases, we are not allowed to have multiple TCP connections. > I learned that this is the case for 3GPP, in particular, due to security > policy as Robert described earlier. However, it is unclear to > me if it is simply a bad choice made by 3GPP, or it is due to some > technical reasons that are more generic than 3GPP. This is something > I would like to figure out during this discussion. > My personal opinion is that this security model is broken. It is usual to have ephemeral source ports and I can't see how it helps to nail down the source port. RFC 3261 section 18 says that the source port is 'often ephemeral'. Moreoever, 3261 describes having a 'dwell time' for a connection to allow a transaction to complete within a single connection. After this time, the connection is/can be closed. The 'fixed port' model means that you can't re-open a connection within the time-wait time... ... also all the text in section 18 about error conditions and re-opening connections seems to be rendered unusable in this scenario... > > This implementation suggestion: > > > > > > A possible implementation could be: > > > > - Transport looks at the first byte of the message, and > > > > cheks whether it starts with 11111. > > > > - If yes, the stream is passed to SigComp that reads it > > > > till 0xFFFF and returns > > > > - If no, the stream is passed to SIP that reads it as > > > > long as indicated by Content-Length > > > > - Rinse, Repeat > > > > makes it sound easy, but the throw-away 'is passed to' seems to me to > > conceal all of the complexity / layering problems / tricky stuff... > > I do agree this doesn't look nice in the layering diagram. However, > I don't think it is complex or tricky to implement. SigComp already > requires quite interactions with SIP layer anyway. Or, perhaps I > missed something here? > I agree that there are significant interactions between SIP and SigComp. However, these are all defined in RFC 3320. The point is that SigComp should (from a transport perspective) be able to look (mostly) like an alternative transport for SIP. Multiplexing really breaks that model. I think my point is that *not* allowing multiplexing means that you can separate the implementation details. (You don't have to if you don't want to, but you *can*). If you insist on allowing multiplexing, then a receiving endpoint *must* support it, and that's going to put a bunch of constraints and requirements on the implementation. I don't think that those constraints need to be there, and so I'd prefer not to have them... _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 08:46:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10105 for ; Fri, 14 Nov 2003 08:46:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeGy-0007s0-IE for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 08:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEDk4lg030246 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 08:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeGy-0007rl-8x for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 08:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10079 for ; Fri, 14 Nov 2003 08:45:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeGw-0005HZ-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 08:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKeGw-0005HU-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 08:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeGw-0007qy-2A; Fri, 14 Nov 2003 08:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeG9-0007a7-0o for rohc@optimus.ietf.org; Fri, 14 Nov 2003 08:45:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09998 for ; Fri, 14 Nov 2003 08:44:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeG7-0005E3-00 for rohc@ietf.org; Fri, 14 Nov 2003 08:45:11 -0500 Received: from [192.116.176.1] (helo=rad-w2ksrv11.radcom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1AKeG5-0005DP-00 for rohc@ietf.org; Fri, 14 Nov 2003 08:45:10 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 14 Nov 2003 15:42:31 +0200 Message-ID: <93E3C7B04652BC47934B2DE74DC607AC10E366@rad-w2ksrv11.radcom.co.il> Thread-Topic: State management in several SIP scenarios Thread-Index: AcOqtSb2gN5j0nVgS/mIkIMTU08sgg== From: "Gilad Shaham" To: Content-Transfer-Encoding: base64 Subject: [rohc] State management in several SIP scenarios Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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: base64 Content-Transfer-Encoding: base64 SGksDQogDQpJIGhhdmUgc2V2ZXJhbCBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoZSB3YXkgdGhlIHN0 YXRlIG1hbmFnZW1lbnQgd29ya3MgaW4gc2V2ZXJhbCBTSVAgc2NlbmFyaW9zLg0KIA0KMS4gSW4g VURQLCBzdXBwb3NlIGFuIGludml0ZSBpcyBzZW50IHRvIGEgcHJveHkgc2VydmVyIGluIFNpZ0Nv bXAuIFRoZSBwcm94eSB0aGVuIHJlc3BvbmRzIHdpdGggMTAwIHRyeWluZywgYW5kIHBlcmhhcHMg c2V2ZXJhbCBwcm92aXNpb25hbCByZXNwb25zZXMsIGFsbCBjb21wcmVzc2VkLiBOb3JtYWxseSwg dGhlIHByb3h5IHdpbGwgbm90IGhhdmUgYSByZXNwb25zZSBmb3IgdGhlc2UgbWVzc2FnZXMsIGFu ZCB0aGVyZWZvcmUgaXQgd2lsbCBub3QgaGF2ZSBhbnkgYWNrZWQgc3RhdGVzLiBBcyBhIHJlc3Vs dCwgdGhlIHByb3h5IHdpbGwgbm90IGJlIGFibGUgdG8gYXNzdW1lIGFueSBzdGF0ZSBoYXMgYmVl biBzYXZlZCBiZWNhdXNlIGl0IGNvdWxkIHJlc3VsdCBpbiBhIGRlY29tcHJlc3Npb24gZmFpbHVy ZSwgaW4gY2FzZSB0aGUgcHJldmlvdXMgbWVzc2FnZSB3YXMgbG9zdC4gVGhlcmVmb3JlLCBlYWNo IG1lc3NhZ2Ugd2lsbCBoYXZlIHRvIGJlIHNlbnQgd2l0aCB0aGUgb3JpZ2luYWwgc3RhdGUgLSBh bmQgaW4gY2FzZSB0aGVyZSB3YXMgbm8gc3RhdGUsIHRoZSBkZWNvbXByZXNzaW9uIGNvZGUgd2ls bCBoYXZlIHRvIGJlIHNlbnQgZWFjaCB0aW1lLiBUaGlzIGlzIHZlcnkgd2FzdGVmdWwgc2luY2Ug dGhlIHN0YXRlIG1lY2hhbmlzbSBpcyBubyB1dGlsaXplZC4gV2hhdCBpcyB0aGUgYmVzdCByZWNv bW1lbmRhdGlvbiBmb3IgaGFuZGxpbmcgc3VjaCBzaXR1YXRpb25zPyANCiANCjIuIFRoaXMgaXMg YSB2YXJpYXRpb24gb2YgdGhlIHByZXZpb3VzIHByb2JsZW0sIGl0J3MgcG9zc2libGUgYm90aCBo YXZlIHRoZSBzYW1lIHNvbHV0aW9uLiBJZiB0d28gVUFzIHNlbmQgU0lQIG1lc3NhZ2VzIGNvbXBy ZXNzZWQgdmlhIFNpZ0NvbXAsIFVBIDEgc2VuZHMgYW4gaW52aXRlLCBVQSAyIHNlbmRzIGEgMjAw IE9LIChwaWdneWJhY2tpbmcgYSBmZWVkYmFjayksIGFuZCBVQSAxIHNlbmRzIGJhY2sgYW4gQUNL IChwaWdneWJhY2tpbmcgYSBmZWVkYmFjaykuIEFzIGEgcmVzdWx0IG9mIHRoZSBsYXN0IEFDSywg VUEgMiBjcmVhdGVzIGEgc3RhdGUsIGJ1dCBkb2VzIG5vdCBzZW5kIGFueSBmZWVkYmFjayBpbmZv cm1hdGlvbi4gVGhlcmVmb3JlLCBVQSAxIG11c3QgdXNlIHRoZSBzdGF0ZSBpdCBnb3QgZnJvbSB0 aGUgMjAwIE9LIG9uIHRoZSBuZXh0IHJlcXVlc3QgKGZvciBleGFtcGxlLCBCWUUpLiBIb3dldmVy LCBDYW4gVUEgMSBiZSBjZXJ0YWluIHRoYXQgVUEgMiBzdGlsbCBoYXMgdGhlIGZpcnN0IHN0YXRl PyBJdCBpcyBwb3NzaWJsZSB0aGUgc2Vjb25kIHN0YXRlIGZvcmNlZCBVQSAyIHRvIHJlbW92ZSB0 aGUgcHJldmlvdXMgc3RhdGUgKGFjY29yZGluZyB0byB0aGUgcmV0ZW50aW9uIHByaW9yaXR5KS4g SXMgaXQgcG9zc2libGUgdGhhdCBVQSAyIG1heSBub3QgZGVsZXRlIHRoZSBwcmV2aW91cyBzdGF0 ZSB1bnRpbCBpdCBoYXMgY29uZmlybWVkIHRoYXQgVUEgMSBoYXMgaXQ/DQogDQozLiBUd28gVUFz IHNlbmQgU0lQIG1lc3NhZ2VzIGNvbXByZXNzZWQgdmlhIFNpZ0NvbXAgd2l0aCBhIHByb3h5IGJl dHdlZW4gdGhlbSB0aGF0IHN1cHBvcnRzIFNpZ0NvbXAsIGVhY2ggb2YgdGhlbSB1c2luZyBhIGRp ZmZlcmVudCBjb21wcmVzc2lvbiBhbGdvcml0aG0gKHN1cHBvc2UgZWFjaCBvbmUgaXMgZnJvbSBh IGRpZmZlcmVudCB2ZW5kb3IpLiBUaGUgcHJveHkgYWRkcyBhIFZpYSBoZWFkZXIsIHRoZXJlZm9y ZSwgbXVzdCBkZWNvbXByZXNzIGVhY2ggbWVzc2FnZSwgYWRkIGl0cyBoZWFkZXIsIGFuZCBjb21w cmVzcyBpdC4gSG93ZXZlciwgdGhlIHByb3h5IG5lZWRzIHRvIGNyZWF0ZSBpdHMgb3duIHN0YXRl IGZvciB0aGUgc2Vjb25kIFVBLiBUaGUgc2Vjb25kIFVBIHJlY2VpdmVzIHRoZSBtZXNzYWdlIGFu ZCBjcmVhdGVzIHRoZSBhcHByb3ByaWF0ZSBzdGF0ZSwgdGhhdCBtYXRjaGVzIHRoZSBjb21wcmVz c2lvbiBhbGdvcml0aG0gdXNlZCBpbiB0aGUgcHJveHksIGFuZCBub3QgaW4gZmlyc3QgVUEuIFdo YXQgaWYgdGhlIElOVklURSBhbmQgMjAwIE9LIHdlcmUgc2VuZCB0aHJvdWdoIHRoZSBwcm94eSwg YnV0IHRoZSBBQ0sgaXMgc2VudCBkaXJlY3RseSBmcm9tIFVBIDEgdG8gVUEgMiBhbmQgbm90IHZp YSB0aGUgcHJveHkuIFNob3VsZCBVQSAxIHJlYWxpemUgdGhhdCB0aGUgc2Vjb25kIFVBIGRvZXMg bm90IGhhdmUgYW55IHN0YXRlIHN0b3JlZCBhbmQgc2VuZCB0aGUgZW50aXJlIHN0YXRlPyBJZiB0 aGlzIGlzIHRoZSBjb3JyZWN0IHNvbHV0aW9uLCBkb2VzIHRoaXMgbWVhbiB0aGF0IGEgZGlhbG9n IGNhbm5vdCBiZSB1c2VkIGZvciBpZGVudGlmeWluZyBhIGNvbXBhcnRtZW50LCBidXQgdGhlIHJl bW90ZSBVUkkgaGFzIHRvIGJlIHVzZWQ/DQo= _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 09:11:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10909 for ; Fri, 14 Nov 2003 09:11:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKef8-0000bM-SC for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 09:11:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEEB25r002306 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 09:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKef8-0000b7-MR for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 09:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10891 for ; Fri, 14 Nov 2003 09:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKef6-0005bc-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 09:11:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKef6-0005bZ-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 09:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKef6-0000an-Dv; Fri, 14 Nov 2003 09:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeeD-0000ZN-JL for rohc@optimus.ietf.org; Fri, 14 Nov 2003 09:10:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10872 for ; Fri, 14 Nov 2003 09:09:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeeB-0005b1-00 for rohc@ietf.org; Fri, 14 Nov 2003 09:10:03 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AKeeA-0005ac-00 for rohc@ietf.org; Fri, 14 Nov 2003 09:10:03 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Nov 2003 14:09:30 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRP4DH; Fri, 14 Nov 2003 14:09:21 -0000 From: "West, Mark" To: "Jan Christoffersson (LU/EAB)" Cc: zhigang.c.liu@nokia.com, Robert.Sugar@nokia.com, rohc@ietf.org Date: Fri, 14 Nov 2003 14:09:16 +0000 (GMT Standard Time) Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection In-Reply-To: Message-ID: References: X-X-Sender: maw1@maw-laptop.roke.co.uk 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: , Hi Jan, Comments added! Cheers, Mark. > > 1. The extra delay caused by opening and closing TCP connections when > switching between SIP and SigComp should not be neglected. In some cases > it may be of little concern but in others it may be important. Reducing > delay has been the most important driving factor for SigComp. > Multiplexing over the same connection reduces the delay. > But most of the cases where you want to switch between SigComp / non-SigComp are inherently cases where there is inherent latency. And RFC 3261 (if I read it correctly, but I'm no SIP guru), talks about only try to keep a transaction within in a single connection... > 2. We have the tools needed for multiplexing SigComp and SIP on the > same TCP connection. Why not do it? It's faster than opening a new > connection. > But the 'tools' are horrible! Reiterating the sentiments from S-F: 'yeah, you could, but why would you want to..?' > 3. Mark argues that if multiplexing is allowed, the receiver needs to > support it. But doesn't it already need to do this? As Zhigang pointed > out, RFC3486 states that > > "If a SIP client sends a compressed request and the client transaction > times out without having received any response, the client SHOULD > retry the same request without using compression. If the compressed > request was sent over a TCP connection, the client SHOULD close that > connection and open a new one to send the uncompressed request." > > In this text, it says SHOULD and not MUST, i.e. there could be > implementations that send SIP and SigComp on the same TCP connection, so > all implementations should be able to handle it. In any case, we have > delimiters to determine where SigComp messages start and end, and if > there is something other than SigComp in between an end and a start, we > should be able to handle it. > That is slicing a semantic a shade too thin for me! But, if you want to play word games, then I'll point out that 'uncompressed' does not mean 'do not use SigComp'. Carsten & I have whipped up a nice little 13-byte standard header: 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, 0x86, 0x01, 0x16, 0xf9, 0x23, ... that will simply output the following bytes! It's a SigComp message, but there's no compression... And let's not forget that the purpose of draft-ietf-rohc-sip-sigcomp is to fill in the missing pieces of the mapping jigsaw (i.e. the bits that aren't in RFC 3486). And that's what we're arguing about. (Although I was fairly sure that we'd already decided this. *sigh*) > I feel that we should allow multiplexing of SigComp and SIP on the same > TCP connection. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 10:46:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16724 for ; Fri, 14 Nov 2003 10:46:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg96-0000A7-Ld for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 10:46:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFk4wL000623 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 10:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg96-00009y-HH for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16692 for ; Fri, 14 Nov 2003 10:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg94-0007UY-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 10:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKg93-0007UV-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 10:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg94-00008x-I7; Fri, 14 Nov 2003 10:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg8i-00007p-QU for rohc@optimus.ietf.org; Fri, 14 Nov 2003 10:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16666 for ; Fri, 14 Nov 2003 10:45:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg8g-0007Rw-00 for rohc@ietf.org; Fri, 14 Nov 2003 10:45:38 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AKg8f-0007RL-00 for rohc@ietf.org; Fri, 14 Nov 2003 10:45:37 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Nov 2003 15:45:06 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRP42S; Fri, 14 Nov 2003 15:44:59 -0000 From: "West, Mark" To: Carsten Bormann Cc: rohc@ietf.org Date: Fri, 14 Nov 2003 15:44:54 +0000 (GMT Standard Time) Subject: Re: [rohc] sigcomp-sip status In-Reply-To: <81112C31-15EC-11D8-90E6-00039390397C@tzi.org> Message-ID: References: <81112C31-15EC-11D8-90E6-00039390397C@tzi.org> X-X-Sender: maw1@maw-laptop.roke.co.uk 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: , Hi all, A bit of a follow-up, as promised/threatened... ... and I reserve the right to include errors of my own..! ;-) > > 2 K SMS means > -- can't compress to stateless proxies (i.e., "really stateless" > proxies can't advertise sigcomp) > 0 K SMS means > -- can't establish state in initial message and rely on it > -- can still assume it's there -- need to wait for ACK to find out > for real > Mark will find a number for what 0 K SMS "costs". > I'm assuming the following simple sequence of 3 messages in a one-way flow: REGISTER, INVITE, and ACK. These have been run through a script that I use for assessing compression efficiency. For these results, the compression algorithm is EPIC (from the SigComp users' guide), 'cause that's what I happen to have to hand... The uncompressed message sizes are 322, 489 and 288 bytes, respectively. The EPIC bytecode that I'm currently playing with is ~400 bytes. So: Per-message compression with static dictionary gives: 126, 201 & 131 bytes = 458 bytes in total (not including SigComp message overhead or bytecode) Bytecode adds 400 bytes to each message. This, it can be seen, is not terribly good value! If bytecode were known to be available (advertised by remote endpoint), some of this overhead could be avoided. Dynamic compression (also with static dictionary) gives: 126, 157 & 23 bytes = 306 bytes total (not including overheads) Bytecode adds 400 bytes to first message. If you deferred the creation of state until receiving the advertisement of 2k SMS, then it would look (as expected), like: 126, 201 & 23 bytes = 350 bytes total (not including overheads) Bytecode adds 400 bytes to the first 2 messages (excepting advertisements or well-known bytecode) As an observation, I can't see any reason why you would use the last case! If it is *possible* that SMS will be available, and you know that it will be at least 2k, then why not make an 'optimistic' state-creation request on the first message? If no SMS is advertised / no ack is received in a response, then you have to use per-message / stateless compression. If, however, SMS is advertised / an ack is received, then everything should proceed exactly as if you had known that there was 2k SMS all along..! For the per-message / boot-strap case, we've played around a bit with compact byte-code for simple compression such that the compressed message + bytecode is still smaller than the original message. The 'best-case' though, would clearly be to have a 'well-known' algorithm that could be used for the per-message / stateless scenario. Hopefully that more or less answers the question..? Cheers, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 11:40:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19484 for ; Fri, 14 Nov 2003 11:40:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgzM-0004zO-Gp for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 11:40:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEGe4g9019172 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 11:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgzL-0004z9-P6 for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 11:40:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19456 for ; Fri, 14 Nov 2003 11:39:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgzK-0000eu-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 11:40:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKgzK-0000er-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 11:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgzJ-0004yt-AO; Fri, 14 Nov 2003 11:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgyU-0004wn-Bi for rohc@optimus.ietf.org; Fri, 14 Nov 2003 11:39:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19436 for ; Fri, 14 Nov 2003 11:38:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgyT-0000ea-00 for rohc@ietf.org; Fri, 14 Nov 2003 11:39:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKgyS-0000eR-00 for rohc@ietf.org; Fri, 14 Nov 2003 11:39:08 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAEGd6A10393 for ; Fri, 14 Nov 2003 18:39:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Nov 2003 18:39:06 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 18:39:06 +0200 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id SAA05461; Fri, 14 Nov 2003 18:39:08 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hAEIcQiZ007335; Fri, 14 Nov 2003 20:38:26 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hAEIcPAm007334; Fri, 14 Nov 2003 20:38:25 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: "zhigang.c.liu@nokia.com" Cc: , , X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B808E8C3@ajebe001.americas.nokia.com> ("zhigang.c.liu@nokia.com"'s message of "Wed, 12 Nov 2003 18:50:28 -0500") References: <7B5AF06E216CB74DA8A5960A3181B5B808E8C3@ajebe001.americas.nokia.com> Date: Fri, 14 Nov 2003 20:38:25 +0200 Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 14 Nov 2003 16:39:06.0318 (UTC) FILETIME=[D1E836E0:01C3AACD] Subject: [rohc] Re: multiplexing SigComp and non-SigComp messages on the same TCP connection Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , "zhigang.c.liu@nokia.com" writes: >- In certain cases, we are not allowed to have multiple TCP connections. >I learned that this is the case for 3GPP, in particular, due to security >policy as Robert described earlier. However, it is unclear to >me if it is simply a bad choice made by 3GPP, or it is due to some >technical reasons that are more generic than 3GPP. This is something >I would like to figure out during this discussion. I'd hazard to say that this is simply a series of bad choices made by MMUSIC, IPSEC, 3GPP and this working group. ;) In any case, SigComp relies on external protocol to provide it with security. The SIP does not provide such protection, so it is up to lower layers. 3GPP chose IPSEC because SIP uses UDP, so they could not use TLS. IPSEC does not naturally provide security at application layer like that SIP requires here, so 3GPP made an IPSEC hack that secures only one UDP and TCP connection at a time. Personally I'd like to blame ITU-T, because they specified horribly complex H.323 so that it simply had to be destroyed by SIP, and only selling argument SIP had back then was that it was simple and used UDP. In any case, I don't think 3GPP is going to change their rel5 security solution any more (it has been tried many time before and now they are almost complete with next release). >> This implementation suggestion: >> > > A possible implementation could be: >> > > - Transport looks at the first byte of the message, and >> > > cheks whether it starts with 11111. >> > > - If yes, the stream is passed to SigComp that reads it >> > > till 0xFFFF and returns >> > > - If no, the stream is passed to SIP that reads it as >> > > long as indicated by Content-Length >> > > - Rinse, Repeat >> makes it sound easy, but the throw-away 'is passed to' seems to me to >> conceal all of the complexity / layering problems / tricky stuff... >I do agree this doesn't look nice in the layering diagram. However, >I don't think it is complex or tricky to implement. SigComp already >requires quite interactions with SIP layer anyway. Or, perhaps I >missed something here? Speaking from SIP point-of-view: SigComp sits on one layer above SIP parser (at transport layer), so this kind of solution fits nicely in the SIP layering. ;-) < Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 11:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20169 for ; Fri, 14 Nov 2003 11:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhEq-0005q8-5a for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 11:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEGu4S3022440 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 11:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhEp-0005pn-R0 for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 11:56:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20146 for ; Fri, 14 Nov 2003 11:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKhEo-0000w7-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 11:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKhEo-0000w4-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 11:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhEn-0005ou-Qw; Fri, 14 Nov 2003 11:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhEW-0005oC-HE for rohc@optimus.ietf.org; Fri, 14 Nov 2003 11:55:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20132 for ; Fri, 14 Nov 2003 11:55:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKhEU-0000vU-00 for rohc@ietf.org; Fri, 14 Nov 2003 11:55:43 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AKhEU-0000vO-00 for rohc@ietf.org; Fri, 14 Nov 2003 11:55:42 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAEGte618084 for ; Fri, 14 Nov 2003 18:55:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Nov 2003 18:55:40 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Nov 2003 18:55:40 +0200 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id SAA05740 for ; Fri, 14 Nov 2003 18:55:43 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hAEIt1iZ007387 for ; Fri, 14 Nov 2003 20:55:01 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hAEIt1DL007386; Fri, 14 Nov 2003 20:55:01 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: rohc@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Fri, 14 Nov 2003 20:55:00 +0200 Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 14 Nov 2003 16:55:40.0576 (UTC) FILETIME=[2287F200:01C3AAD0] Subject: [rohc] Byte copying rules with STATE-ACCESS and END-MESSAGE Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hello all SigComp lawyers, The RFC 3320 does not state whether the byte copying rules should be used when retrieving the partial state identifier given to the STATE-ACCESS operation. Also spec is silent with the requested feedback or returned parameters to the END-MESSAGE operation. The partial state identifier given to STATE-FREE is byte copied, so I'd expect similar parameter to STATE-ACCESS to be byte copied, too. If byte copying rules should *not* be used, it might be a good idea to mention that somewhere, or even add some torture tests to test correct operation. --Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 12:49:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22132 for ; Fri, 14 Nov 2003 12:49:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKi48-00020Q-Qj for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 12:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEHn4v2007707 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 12:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKi48-000208-It for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 12:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22107 for ; Fri, 14 Nov 2003 12:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKi46-0001mW-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 12:49:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKi45-0001mM-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 12:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKi45-0001zA-BV; Fri, 14 Nov 2003 12:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKi39-0001ua-Pf for rohc@optimus.ietf.org; Fri, 14 Nov 2003 12:48:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22067 for ; Fri, 14 Nov 2003 12:47:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKi38-0001lg-00 for rohc@ietf.org; Fri, 14 Nov 2003 12:48:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKi37-0001lZ-00 for rohc@ietf.org; Fri, 14 Nov 2003 12:48:01 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAEHlxA12221 for ; Fri, 14 Nov 2003 19:47:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Nov 2003 19:47:57 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 19:47:58 +0200 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id TAA06396; Fri, 14 Nov 2003 19:48:01 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hAEJlIiZ007557; Fri, 14 Nov 2003 21:47:18 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hAEJlIpb007556; Fri, 14 Nov 2003 21:47:18 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: , zhigang.c.liu@nokia.com, Robert.Sugar@nokia.com, rohc@ietf.org Subject: Re: [rohc] Re: multiplexing SigComp and non-SigComp messages on the same TCP connection X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (West, Mark's message of "Thu, 13 Nov 2003 13:57:24 +0000 (GMT Standard Time)") References: <7B5AF06E216CB74DA8A5960A3181B5B808E8C3@ajebe001.americas.nokia.com> Date: Fri, 14 Nov 2003 21:47:18 +0200 Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 14 Nov 2003 17:47:58.0107 (UTC) FILETIME=[70A52EB0:01C3AAD7] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , West, Mark writes: >...Moreoever, 3261 describes having a 'dwell time' for a >connection to allow a transaction to complete within a single connection. >After this time, the connection is/can be closed. In general, the connection should be kept around for 64*T1 or 32 seconds (or longer, if the client has longer T1 than 500 ms). Because only the client knows its T1 value, it should close the connection, not the server. If the client is a SIP UA behind a NAT box, it wants to keep the connection open for the duration of its registration. If it wants to open another connection, in most cases it has to do a REGISTER request in order to get the new connection authenticated. Because the TCP connections are expensive for the server, it wants to ditch the old one after the new connection has been authenticated. The same happens with a 3GPP UE: if it wants to open a new TCP connection, it has to first re-authenticate itself. The IPSEC protection is given to the new connection using the keys derived from the authentication procedure. The old connection is closed. >The 'fixed port' model >means that you can't re-open a connection within the time-wait time... >... also all the text in section 18 about error conditions and re-opening >connections seems to be rendered unusable in this scenario... They are not unusable, they just have the added penalty of re-running the authentication procedures. BTW, how is the SigComp for TLS? If people are not happy with 3GPP handling security with IPSEC (I'm not saying that they are alone here), they should provide 3GPP with an alternative. >I agree that there are significant interactions between SIP and SigComp. >However, these are all defined in RFC 3320. The point is that SigComp >should (from a transport perspective) be able to look (mostly) like an >alternative transport for SIP. Multiplexing really breaks that model. Well, from SIP transport point of view SigComp looks like just alternative parser for SIP. Transport takes packets (in case of UDP) or streams of bytes (in case of TCP), stuffs them into the parser and gets SIP messages out of it. The combined SIP/SigComp parser can look inside SIP message and give compartment identifier back to SigComp. >I think my point is that *not* allowing multiplexing means that you can >separate the implementation details. (You don't have to if you don't >want to, but you *can*). If you insist on allowing multiplexing, then a >receiving endpoint *must* support it, and that's going to put a bunch >of constraints and requirements on the implementation. I don't think >that those constraints need to be there, and so I'd prefer not to have >them... SigComp has lot of things that break assumptions about transport, especially TCP transport. TCP is a stream of bytes, SigComp provides messages, etc. Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 15:52:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29070 for ; Fri, 14 Nov 2003 15:52:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkvC-000802-Ak for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 15:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEKq25o030746 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 15:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkvC-0007zp-6g for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 15:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29062 for ; Fri, 14 Nov 2003 15:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKkvA-0004AR-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 15:52:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKkvA-0004AO-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 15:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkvA-0007zR-6B; Fri, 14 Nov 2003 15:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkuP-0007yb-LI for rohc@optimus.ietf.org; Fri, 14 Nov 2003 15:51:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29035 for ; Fri, 14 Nov 2003 15:50:59 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKkuN-00049r-00 for rohc@ietf.org; Fri, 14 Nov 2003 15:51:12 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKkuN-00049o-00 for rohc@ietf.org; Fri, 14 Nov 2003 15:51:11 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAEKpAA26095 for ; Fri, 14 Nov 2003 22:51:10 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Nov 2003 22:51:09 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 12:51:07 -0800 content-class: urn:content-classes:message Subject: RE: [rohc] sigcomp-sip status MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Nov 2003 15:51:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8C8@ajebe001.americas.nokia.com> Thread-Topic: [rohc] sigcomp-sip status Thread-Index: AcOqxnoCEm+5RhrrQbaXfoCEhNST9AAIJl0g To: , Cc: X-OriginalArrivalTime: 14 Nov 2003 20:51:07.0804 (UTC) FILETIME=[0703DDC0:01C3AAF1] 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 > As an observation, I can't see any reason why you would use=20 > the last case! > If it is *possible* that SMS will be available, and you know=20 > that it will be at least 2k, then why not make an 'optimistic'=20 > state-creation request on the first message? If no SMS is=20 > advertised / no ack is received in a response, then you have=20 > to use per-message / stateless compression. If, however,=20 > SMS is advertised / an ack is received, then everything should > proceed exactly as if you had known that there was 2k SMS all along..! This is true in this example. However, the example has two assumptions: a) The state is only the bytecode --> you have to upload it in the=20 first message anyway. b) Each message always triggers a message on the reverse direction --> you'll know the truth when you send the second message, just in time before you have to guess. If *either* of the assumptions is untrue, we can no longer say 0KB SMS costs nothing. - For example, if assumption b) is untrue, we may have endpoint A sends two messages (message 1 and 2) in a row before endpoint B returns a response. Then, should A send bytecode state in message 2? For SigComp over TCP, the bytecode in message 2 can be avoided if A knows the SMS of B > 0. - RE assumption a), A may want to upload dictionary state in the first=20 message, which can be used to compressed the second or even subsequent=20 messages it is going to send. This is particularly useful if the delay=20 of the first message is not important (which is the case for REGISTER).=20 However, without knowing whether B has SMS > 0, how can A decide whether to upload the dictionary state and enjoy the reward latter? Unlike = uploading bytecode state in the first message (which you have to anyway), your investment may or may not lead to any benefit depending on SMS of B. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 14 17:14:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01383 for ; Fri, 14 Nov 2003 17:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKmCY-0005FE-S0 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 17:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEME23X020154 for rohc-archive@odin.ietf.org; Fri, 14 Nov 2003 17:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKmCY-0005Ez-NF for rohc-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 17:14:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01370 for ; Fri, 14 Nov 2003 17:13:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKmCW-0005Az-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 17:14:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKmCW-0005Aw-00 for rohc-web-archive@ietf.org; Fri, 14 Nov 2003 17:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKmCX-0005Ej-By; Fri, 14 Nov 2003 17:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKmCR-0005EM-FF for rohc@optimus.ietf.org; Fri, 14 Nov 2003 17:13:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01357 for ; Fri, 14 Nov 2003 17:13:40 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKmCO-0005Ac-00 for rohc@ietf.org; Fri, 14 Nov 2003 17:13:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKmCO-0005AY-00 for rohc@ietf.org; Fri, 14 Nov 2003 17:13:52 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAEMDqA04400 for ; Sat, 15 Nov 2003 00:13:52 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 15 Nov 2003 00:13:51 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 14:12:36 -0800 content-class: urn:content-classes:message Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Nov 2003 17:12:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8C9@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcOquPTs03RLuyrEQKWjcEHdMvg8VwAOSQNg To: , Cc: , X-OriginalArrivalTime: 14 Nov 2003 22:12:36.0179 (UTC) FILETIME=[68B6B230:01C3AAFC] 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 Mark, > That is slicing a semantic a shade too thin for me! But, if=20 > you want to play word games, then I'll point out that=20 > 'uncompressed' does not mean 'do not use SigComp'. I don't think Jan is playing word game here. Few people really=20 enjoy it. SHOULD and MUST are well defined words in IETF. This is no point to argue that further.=20 RE "uncompressed". Evidently and unfortunately, people used it with=20 different meanings in mind. And in fact, it remains arguable if a = sigcomp message encapsulating an uncompressed SIP message can be really called = an=20 "uncompressed message". One may say it is still a compressed message,=20 but with NULL compression algorithm (like the NULL encryption algorithms for IPsec). This starts looking like a word game, so, I'd better just=20 stop here. Anyway, we already agreed to non-sigcomp messages when we do mean non-sigcomp message. This is not my point. My point is that when RFC 3261 states: "... the client SHOULD close that connection and open a new one to send the uncompressed request.", it *should* mean to send non-SigComp messages on the new TCP connection. = Logically, if the sender suspects a SigComp failure (see futher below) has happened, it should avoid using SigComp. > Carsten & I have whipped up a nice little 13-byte standard header: >=20 > 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, > 0x86, 0x01, 0x16, 0xf9, 0x23, ... >=20 > that will simply output the following bytes! Nice code indeed. For those who are wondering, the first 3 bytes are SigComp header. And the remaining 10 bytes are the decompression byte code: INPUT-BYTES(1, 64, +9), OUTPUT(64, 1), Jump(-7),=20 END-MESSAGE(with zeros operands initialized by UDVM). This should work fine to resolve the SigComp failures due to state desynchronization. But what if the UDVM somehow malfunctions so that=20 it cannot execute the bytecode correctly? Of course, this should=20 rarely happen, but is still a possibility as we're talking about SigComp failures. (Also, as a less important issue, it takes time for the UDVM execute the byte-by-byte I/O instructions. Of course, a smart implementation may analyze/compile the code instead of interpreting it. But can we assume that?) BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sat Nov 15 09:43:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08580 for ; Sat, 15 Nov 2003 09:43:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL1dh-0002Ng-04 for rohc-archive@odin.ietf.org; Sat, 15 Nov 2003 09:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFEh4gk009148 for rohc-archive@odin.ietf.org; Sat, 15 Nov 2003 09:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL1dg-0002NT-TL for rohc-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 09:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08566 for ; Sat, 15 Nov 2003 09:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL1de-0000kV-00 for rohc-web-archive@ietf.org; Sat, 15 Nov 2003 09:43:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AL1de-0000kR-00 for rohc-web-archive@ietf.org; Sat, 15 Nov 2003 09:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL1dd-0002N0-SP; Sat, 15 Nov 2003 09:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL1dM-0002MN-SV for rohc@optimus.ietf.org; Sat, 15 Nov 2003 09:42:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08554 for ; Sat, 15 Nov 2003 09:42:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL1dK-0000kC-00 for rohc@ietf.org; Sat, 15 Nov 2003 09:42:42 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AL1dK-0000jZ-00 for rohc@ietf.org; Sat, 15 Nov 2003 09:42:42 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hAFEg9D3055857 for ; Sat, 15 Nov 2003 15:42:11 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hAFEg97a055856 for ; Sat, 15 Nov 2003 15:42:09 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hAFEg7Cx055853; Sat, 15 Nov 2003 15:42:09 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5D36AD3955; Sat, 15 Nov 2003 15:42:05 +0100 (CET) Date: Sat, 15 Nov 2003 15:43:37 +0100 From: Juergen Quittek To: "C. M. Heard" Cc: ROHC mailing list , "Wijnen, Bert (Bert)" Subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Message-ID: <2147483647.1068911017@[10.1.1.26]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 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 Mike, While committing the changes I read again my replies on your comments and there is one point where I am not that sure anymore that it is wrong in the last version. Please see below. --On 09.11.2003 19:17 h +0100 Juergen Quittek wrote: [...] Mike> Another point that I noticed is that the OID assignments for the Mike> columnar objects are not contiguous, doubtless as a result of Mike> removing columns from the tables. Here is the result of a quick Mike> grep: Mike> ::= { rohcChannelEntry 2 } Mike> ::= { rohcChannelEntry 3 } Mike> ::= { rohcChannelEntry 4 } Mike> ::= { rohcChannelEntry 5 } Mike> ::= { rohcChannelEntry 13 } Juergen> Juergen> Yes, this needs to be fixed. Juergen> Mike> ::= { rohcInstanceEntry 2 } Mike> ::= { rohcInstanceEntry 4 } Juergen> Juergen> And this also. Wait ... isn't this correct? Considering the indexing this looks at least not completely wrong to me because object rohcChannelID is already defined as element of the rohcChannelTable: | | +--rohcInstanceTable(2) | | | | | | | +--rohcInstanceEntry(1) [ifIndex,rohcInstanceType,rohcChannelID] | | | | | | | +-- --- Enumeration rohcInstanceType(2) | | | +-- r-n RohcChannelIdentifier rohcInstanceFBChannelID(4) | | | +-- r-n ObjectIdentifier rohcInstanceVendor(5) | | | +-- r-n SnmpAdminString rohcInstanceVersion(6) | | | +-- . . . Mike, can we leave this as it is? If not, what is the correct number assignment? Thanks, Juergen _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sat Nov 15 15:20:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17721 for ; Sat, 15 Nov 2003 15:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL6tq-0001Om-50 for rohc-archive@odin.ietf.org; Sat, 15 Nov 2003 15:20:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFKK5L0005362 for rohc-archive@odin.ietf.org; Sat, 15 Nov 2003 15:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL6to-0001OP-Oz for rohc-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 15:20:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17682 for ; Sat, 15 Nov 2003 15:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL6tn-0004mL-00 for rohc-web-archive@ietf.org; Sat, 15 Nov 2003 15:20:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AL6tn-0004mI-00 for rohc-web-archive@ietf.org; Sat, 15 Nov 2003 15:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL6tm-0001O5-Ae; Sat, 15 Nov 2003 15:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL6t6-0001NE-Jw for rohc@optimus.ietf.org; Sat, 15 Nov 2003 15:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17644 for ; Sat, 15 Nov 2003 15:19:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL6t5-0004lw-00 for rohc@ietf.org; Sat, 15 Nov 2003 15:19:19 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL6t4-0004lt-00 for rohc@ietf.org; Sat, 15 Nov 2003 15:19:18 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id hAFKJAv12503; Sat, 15 Nov 2003 12:19:11 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 15 Nov 2003 12:19:09 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Juergen Quittek cc: ROHC mailing list , "Wijnen, Bert (Bert)" Subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt In-Reply-To: <2147483647.1068911017@[10.1.1.26]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Sat, 15 Nov 2003, Juergen Quittek wrote: > While committing the changes I read again my replies on your comments > and there is one point where I am not that sure anymore that it is > wrong in the last version. Please see below. > > --On 09.11.2003 19:17 h +0100 Juergen Quittek wrote: > > [...] > Mike> Another point that I noticed is that the OID assignments for the > Mike> columnar objects are not contiguous, doubtless as a result of > Mike> removing columns from the tables. Here is the result of a quick > Mike> grep: .... > Mike> ::= { rohcInstanceEntry 2 } > Mike> ::= { rohcInstanceEntry 4 } ... > Wait ... isn't this correct? > > Considering the indexing this looks at least not completely > wrong to me because object rohcChannelID is already defined > as element of the rohcChannelTable: > > | | +--rohcInstanceTable(2) > | | | | > | | | +--rohcInstanceEntry(1) [ifIndex,rohcInstanceType,rohcChannelID] > | | | | > | | | +-- --- Enumeration rohcInstanceType(2) > | | | +-- r-n RohcChannelIdentifier rohcInstanceFBChannelID(4) > | | | +-- r-n ObjectIdentifier rohcInstanceVendor(5) > | | | +-- r-n SnmpAdminString rohcInstanceVersion(6) > | | | +-- . . . > > Mike, can we leave this as it is? > If not, what is the correct number assignment? Normally we don't leave gaps in the OID assignments for columnar objects even if the row object has index components in other tables. However, that is really just a question of style; it is not an error to have gaps in OID assignments. So if you feel strongly about this case I won't object if you choose to leave it as is. Bert may feel differently and I will let him speak for himself. Regards, Mike _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Nov 17 08:02:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10490 for ; Mon, 17 Nov 2003 08:02:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALj11-0005Ki-5V for rohc-archive@odin.ietf.org; Mon, 17 Nov 2003 08:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHD233v020496 for rohc-archive@odin.ietf.org; Mon, 17 Nov 2003 08:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALj11-0005KV-1J for rohc-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 08:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10479 for ; Mon, 17 Nov 2003 08:01:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALj10-0006DI-00 for rohc-web-archive@ietf.org; Mon, 17 Nov 2003 08:02:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALj0z-0006DE-00 for rohc-web-archive@ietf.org; Mon, 17 Nov 2003 08:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALj0y-0005KC-KM; Mon, 17 Nov 2003 08:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALj05-0005J9-FW for rohc@optimus.ietf.org; Mon, 17 Nov 2003 08:01:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10447 for ; Mon, 17 Nov 2003 08:00:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALj04-0006Ai-00 for rohc@ietf.org; Mon, 17 Nov 2003 08:01:04 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ALj03-0006Ac-00 for rohc@ietf.org; Mon, 17 Nov 2003 08:01:03 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHD0vI2010783; Mon, 17 Nov 2003 14:01:02 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 14:00:57 +0100 Message-ID: From: "Jan Christoffersson (LU/EAB)" To: "'West, Mark'" , Carsten Bormann Cc: rohc@ietf.org Subject: RE: [rohc] sigcomp-sip status Date: Mon, 17 Nov 2003 14:00:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I think allowing 0 byte SMS is reasonable. The extra cost of allowing this (if the true size is >0)if the optimistic approach is used is mostly zero. Even if we expect and hope that all client and servers have a non zero SMS, I think we should still allow a zero byte SMS. It could perhaps be useful for temporarily overloaded proxies. Best Regards Jan -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of West, Mark Sent: den 14 november 2003 16:45 To: Carsten Bormann Cc: rohc@ietf.org Subject: Re: [rohc] sigcomp-sip status Hi all, A bit of a follow-up, as promised/threatened... ... and I reserve the right to include errors of my own..! ;-) > > 2 K SMS means > -- can't compress to stateless proxies (i.e., "really stateless" > proxies can't advertise sigcomp) > 0 K SMS means > -- can't establish state in initial message and rely on it > -- can still assume it's there -- need to wait for ACK to find out > for real > Mark will find a number for what 0 K SMS "costs". > I'm assuming the following simple sequence of 3 messages in a one-way flow: REGISTER, INVITE, and ACK. These have been run through a script that I use for assessing compression efficiency. For these results, the compression algorithm is EPIC (from the SigComp users' guide), 'cause that's what I happen to have to hand... The uncompressed message sizes are 322, 489 and 288 bytes, respectively. The EPIC bytecode that I'm currently playing with is ~400 bytes. So: Per-message compression with static dictionary gives: 126, 201 & 131 bytes = 458 bytes in total (not including SigComp message overhead or bytecode) Bytecode adds 400 bytes to each message. This, it can be seen, is not terribly good value! If bytecode were known to be available (advertised by remote endpoint), some of this overhead could be avoided. Dynamic compression (also with static dictionary) gives: 126, 157 & 23 bytes = 306 bytes total (not including overheads) Bytecode adds 400 bytes to first message. If you deferred the creation of state until receiving the advertisement of 2k SMS, then it would look (as expected), like: 126, 201 & 23 bytes = 350 bytes total (not including overheads) Bytecode adds 400 bytes to the first 2 messages (excepting advertisements or well-known bytecode) As an observation, I can't see any reason why you would use the last case! If it is *possible* that SMS will be available, and you know that it will be at least 2k, then why not make an 'optimistic' state-creation request on the first message? If no SMS is advertised / no ack is received in a response, then you have to use per-message / stateless compression. If, however, SMS is advertised / an ack is received, then everything should proceed exactly as if you had known that there was 2k SMS all along..! For the per-message / boot-strap case, we've played around a bit with compact byte-code for simple compression such that the compressed message + bytecode is still smaller than the original message. The 'best-case' though, would clearly be to have a 'well-known' algorithm that could be used for the per-message / stateless scenario. Hopefully that more or less answers the question..? Cheers, Mark. _______________________________________________ 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 Nov 17 08:48:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11621 for ; Mon, 17 Nov 2003 08:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjjW-0007hm-Gc for rohc-archive@odin.ietf.org; Mon, 17 Nov 2003 08:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHDm25G029612 for rohc-archive@odin.ietf.org; Mon, 17 Nov 2003 08:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjjW-0007hS-8m for rohc-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 08:48:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11601 for ; Mon, 17 Nov 2003 08:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjjU-0006l2-00 for rohc-web-archive@ietf.org; Mon, 17 Nov 2003 08:48:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALjjU-0006kz-00 for rohc-web-archive@ietf.org; Mon, 17 Nov 2003 08:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjjU-0007gA-WF; Mon, 17 Nov 2003 08:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjif-0007fb-QM for rohc@optimus.ietf.org; Mon, 17 Nov 2003 08:47:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11575 for ; Mon, 17 Nov 2003 08:46:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjie-0006kN-00 for rohc@ietf.org; Mon, 17 Nov 2003 08:47:08 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ALjid-0006kI-00 for rohc@ietf.org; Mon, 17 Nov 2003 08:47:08 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAHDl6I2027548; Mon, 17 Nov 2003 14:47:07 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 14:47:06 +0100 Message-ID: From: "Jan Christoffersson (LU/EAB)" To: "'West, Mark'" Cc: zhigang.c.liu@nokia.com, Robert.Sugar@nokia.com, rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Mon, 17 Nov 2003 14:46:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Mark, Comments inline. -----Original Message----- From: West, Mark [mailto:mark.a.west@roke.co.uk] Sent: den 14 november 2003 15:09 To: Jan Christoffersson (LU/EAB) Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Hi Jan, Comments added! Cheers, Mark. > > 1. The extra delay caused by opening and closing TCP connections when > switching between SIP and SigComp should not be neglected. In some cases > it may be of little concern but in others it may be important. Reducing > delay has been the most important driving factor for SigComp. > Multiplexing over the same connection reduces the delay. > But most of the cases where you want to switch between SigComp / non-SigComp are inherently cases where there is inherent latency. [JC]I agree that these cases will probably have a lot of latency, so this argument isn't very heavy. Still, less latency is better. And RFC 3261 (if I read it correctly, but I'm no SIP guru), talks about only try to keep a transaction within in a single connection... > 2. We have the tools needed for multiplexing SigComp and SIP on the > same TCP connection. Why not do it? It's faster than opening a new > connection. > But the 'tools' are horrible! Reiterating the sentiments from S-F: 'yeah, you could, but why would you want to..?' [JC]I don't know why this is so horrible? Could you please elaborate... > 3. Mark argues that if multiplexing is allowed, the receiver needs to > support it. But doesn't it already need to do this? As Zhigang pointed > out, RFC3486 states that > > "If a SIP client sends a compressed request and the client transaction > times out without having received any response, the client SHOULD > retry the same request without using compression. If the compressed > request was sent over a TCP connection, the client SHOULD close that > connection and open a new one to send the uncompressed request." > > In this text, it says SHOULD and not MUST, i.e. there could be > implementations that send SIP and SigComp on the same TCP connection, so > all implementations should be able to handle it. In any case, we have > delimiters to determine where SigComp messages start and end, and if > there is something other than SigComp in between an end and a start, we > should be able to handle it. > That is slicing a semantic a shade too thin for me! But, if you want to play word games, then I'll point out that 'uncompressed' does not mean 'do not use SigComp'. [JC] I didn't intend this to be a word game. To me this is a recommendation to open a new TCP connection. I'm perfectly happy with that. But I don't think we should turn the recommendation into a must and forbid sending SigComp and non-SigComp on the same TCP connection. Carsten & I have whipped up a nice little 13-byte standard header: 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, 0x86, 0x01, 0x16, 0xf9, 0x23, ... that will simply output the following bytes! It's a SigComp message, but there's no compression... [JC]Yes, this is perfectly fine, unless the message is larger than 64 K. And let's not forget that the purpose of draft-ietf-rohc-sip-sigcomp is to fill in the missing pieces of the mapping jigsaw (i.e. the bits that aren't in RFC 3486). And that's what we're arguing about. (Although I was fairly sure that we'd already decided this. *sigh*) _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 18 04:31:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11710 for ; Tue, 18 Nov 2003 04:31:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2CQ-0004O5-5X for rohc-archive@odin.ietf.org; Tue, 18 Nov 2003 04:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI9V5Vw016854 for rohc-archive@odin.ietf.org; Tue, 18 Nov 2003 04:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2CP-0004Nd-0p for rohc-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 04:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11671 for ; Tue, 18 Nov 2003 04:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2CM-0001Ft-00 for rohc-web-archive@ietf.org; Tue, 18 Nov 2003 04:31:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM2CL-0001Fq-00 for rohc-web-archive@ietf.org; Tue, 18 Nov 2003 04:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2CM-0004N8-Vt; Tue, 18 Nov 2003 04:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2Bg-0004Lc-Nm for rohc@optimus.ietf.org; Tue, 18 Nov 2003 04:30:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11641 for ; Tue, 18 Nov 2003 04:30:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2Bd-0001FC-00 for rohc@ietf.org; Tue, 18 Nov 2003 04:30:17 -0500 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx with esmtp (Exim 4.12) id 1AM2Bc-0001Es-00 for rohc@ietf.org; Tue, 18 Nov 2003 04:30:17 -0500 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp3.clb.oleane.net with SMTP id hAI9TjTa000670 for ; Tue, 18 Nov 2003 10:29:45 +0100 Message-ID: <02a701c3adb7$1c3101a0$0601a8c0@www.oleane.com> From: "mwinkhler" To: Date: Tue, 18 Nov 2003 10:34:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A4_01C3ADBF.7D76C3C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [rohc] 2004 WiFi Voice Conference Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_02A4_01C3ADBF.7D76C3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The 2004 WiFi Voice Conference will stand in Paris on May 25 to 28, = 2004.=20 The call for papers dead line has been extended until December 15, 2003. = Get more details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm We also remind you that registration is still open to the New Mobile = Technologies Forum (UWB, IPCN and IPv6 Mobile sessions) at: http://www.upperside.fr/newmobtech/newmobtech03intro.htm ------=_NextPart_000_02A4_01C3ADBF.7D76C3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The 2004 WiFi Voice=20 Conference will stand in Paris on May 25 to=20 28, 2004. 
The call for papers dead line has been = extended until=20 December 15, 2003.
Get more details at:
http://= www.upperside.fr/wifivoice04/wifivoice04intro.htm
 
We also remind you that registration is still open to the New Mobile Technologies Forum (UWB, IPCN and IPv6 = Mobile=20 sessions) at:
http://= www.upperside.fr/newmobtech/newmobtech03intro.htm
<= /DIV>
 
 
 
------=_NextPart_000_02A4_01C3ADBF.7D76C3C0-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 19 10:25:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21693 for ; Wed, 19 Nov 2003 10:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUCY-0001Cc-W1 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 10:25:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFP6a1004620 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 10:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUCY-0001CR-Km for rohc-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:25:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21681 for ; Wed, 19 Nov 2003 10:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUCW-00014p-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 10:25:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMUCW-00014l-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 10:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUCU-0001CA-3l; Wed, 19 Nov 2003 10:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUCH-0001Bd-3x for rohc@optimus.ietf.org; Wed, 19 Nov 2003 10:24:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21675 for ; Wed, 19 Nov 2003 10:24:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUCE-00014f-00 for rohc@ietf.org; Wed, 19 Nov 2003 10:24:46 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AMUCE-00014P-00 for rohc@ietf.org; Wed, 19 Nov 2003 10:24:46 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Nov 2003 15:24:12 -0000 Message-ID: From: "West, Mark" To: "'zhigang.c.liu@nokia.com'" , cabo@tzi.org Cc: rohc@ietf.org Subject: RE: [rohc] sigcomp-sip status Date: Wed, 19 Nov 2003 15:24:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zhigang, Regarding a), I agree with you. This is a counter-example that I had not considered. So, yes, if you don't know that the endpoint has SMS available, you may decide not to upload user-specific dictionary state, and there may well be a cost associated with that. I'm not in a position to quantify that at the moment, but I accept the point. So far as b) is concerned, I don't think that this is (necessarily) just an SMS issue (although it is a valid point). If I send 2 messages to the remote endpoint without receiving feedback, how do I know that the message has successfully arrived; been correctly decompressed; and that the SIP application has authorised the state creation? If *any* of those are false, then I can't make use of the state, even if remote SMS is available. (Use of TCP makes the first likely, but doesn't impact the others...) Cheers, Mark. > > This is true in this example. However, the example has two > assumptions: > > a) The state is only the bytecode --> you have to upload it in the > first message anyway. > > b) Each message always triggers a message on the reverse direction > --> you'll know the truth when you send the second message, just in > time before you have to guess. > > If *either* of the assumptions is untrue, we can no longer say 0KB SMS > costs nothing. > > - For example, if assumption b) is untrue, we may have endpoint A > sends two messages (message 1 and 2) in a row before endpoint > B returns > a response. Then, should A send bytecode state in message 2? > For SigComp > over TCP, the bytecode in message 2 can be avoided if A knows the SMS > of B > 0. > > - RE assumption a), A may want to upload dictionary state in > the first > message, which can be used to compressed the second or even > subsequent > messages it is going to send. This is particularly useful if > the delay > of the first message is not important (which is the case for > REGISTER). > However, without knowing whether B has SMS > 0, how can A > decide whether > to upload the dictionary state and enjoy the reward latter? > Unlike uploading > bytecode state in the first message (which you have to anyway), your > investment may or may not lead to any benefit depending on SMS of B. > > BR, > Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 19 10:32:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21990 for ; Wed, 19 Nov 2003 10:32:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUJG-0001Sj-80 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 10:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFW2mx005615 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUJG-0001SU-4O for rohc-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:32:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21967 for ; Wed, 19 Nov 2003 10:31:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUJD-0001CA-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 10:31:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMUJD-0001C7-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 10:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUJE-0001SE-Lr; Wed, 19 Nov 2003 10:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUJ2-0001RR-3X for rohc@optimus.ietf.org; Wed, 19 Nov 2003 10:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21959 for ; Wed, 19 Nov 2003 10:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUIz-0001Bp-00 for rohc@ietf.org; Wed, 19 Nov 2003 10:31:45 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AMUIz-00019T-00 for rohc@ietf.org; Wed, 19 Nov 2003 10:31:45 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Nov 2003 15:31:13 -0000 Message-ID: From: "West, Mark" To: "'Jan Christoffersson (LU/EAB)'" Cc: zhigang.c.liu@nokia.com, Robert.Sugar@nokia.com, rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Wed, 19 Nov 2003 15:31:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Jan, Yes, less latency is good (that has always been a goal of SigComp). And I agree that messages > 64kbyte are a problem with SigComp! Still, you can't win 'em all... Multiplexing is horrible (or, at the very least messy) because you inherently bind the SigComp and SIP transport handling for detecting the end of a message. If you don't allow multiplexing, you are free to implement it this way (if you want), but if you *do* allow multiplexing then this becomes a requirement... But, like I say, I thought that the 'non-multiplexing' issue had been agreed. And it's still not clear to me why it's important to be able to do it! Cheers, Mark. > -----Original Message----- > From: Jan Christoffersson (LU/EAB) > [mailto:jan.christoffersson@ericsson.com] > Sent: 17 November 2003 13:47 > To: West, Mark > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; rohc@ietf.org > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > messages on > t he same TCP connection > > > Hi Mark, > > Comments inline. > > -----Original Message----- > From: West, Mark [mailto:mark.a.west@roke.co.uk] > Sent: den 14 november 2003 15:09 > To: Jan Christoffersson (LU/EAB) > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; rohc@ietf.org > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > messages on > t he same TCP connection > > > > Hi Jan, > > Comments added! > > Cheers, > > Mark. > > > > > 1. The extra delay caused by opening and closing TCP > connections when > > switching between SIP and SigComp should not be neglected. > In some cases > > it may be of little concern but in others it may be > important. Reducing > > delay has been the most important driving factor for SigComp. > > Multiplexing over the same connection reduces the delay. > > > > But most of the cases where you want to switch between SigComp / > non-SigComp are inherently cases where there is inherent latency. > > [JC]I agree that these cases will probably have a lot of > latency, so this argument isn't very heavy. Still, less > latency is better. > > And RFC 3261 (if I read it correctly, but I'm no SIP guru), > talks about > only try to keep a transaction within in a single connection... > > > 2. We have the tools needed for multiplexing SigComp and SIP on the > > same TCP connection. Why not do it? It's faster than opening a new > > connection. > > > > But the 'tools' are horrible! Reiterating the sentiments > from S-F: 'yeah, > you could, but why would you want to..?' > > [JC]I don't know why this is so horrible? Could you please > elaborate... > > > 3. Mark argues that if multiplexing is allowed, the > receiver needs to > > support it. But doesn't it already need to do this? As > Zhigang pointed > > out, RFC3486 states that > > > > "If a SIP client sends a compressed request and the client > transaction > > times out without having received any response, the client SHOULD > > retry the same request without using compression. If > the compressed > > request was sent over a TCP connection, the client > SHOULD close that > > connection and open a new one to send the uncompressed request." > > > > In this text, it says SHOULD and not MUST, i.e. there could be > > implementations that send SIP and SigComp on the same TCP > connection, so > > all implementations should be able to handle it. In any > case, we have > > delimiters to determine where SigComp messages start and end, and if > > there is something other than SigComp in between an end and > a start, we > > should be able to handle it. > > > > That is slicing a semantic a shade too thin for me! But, if > you want to > play word games, then I'll point out that 'uncompressed' does > not mean 'do > not use SigComp'. > [JC] I didn't intend this to be a word game. To me this is a > recommendation to open a new TCP connection. I'm perfectly > happy with that. But I don't think we should turn the > recommendation into a must and forbid sending SigComp and > non-SigComp on the same TCP connection. > > Carsten & I have whipped up a nice little 13-byte standard header: > > 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, > 0x86, 0x01, 0x16, 0xf9, 0x23, ... > > that will simply output the following bytes! > > It's a SigComp message, but there's no compression... > > [JC]Yes, this is perfectly fine, unless the message is larger > than 64 K. > > And let's not forget that the purpose of > draft-ietf-rohc-sip-sigcomp is to > fill in the missing pieces of the mapping jigsaw (i.e. the bits that > aren't in RFC 3486). And that's what we're arguing about. > (Although I > was fairly sure that we'd already decided this. *sigh*) > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 19 10:55:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23024 for ; Wed, 19 Nov 2003 10:55:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUfW-0002uN-PQ for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 10:55:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFt2DP011173 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 10:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUfW-0002u8-Em for rohc-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:55:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23000 for ; Wed, 19 Nov 2003 10:54:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUfT-0001cz-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 10:54:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMUfT-0001cw-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 10:54:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUfV-0002tn-6f; Wed, 19 Nov 2003 10:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUek-0002sG-NK for rohc@optimus.ietf.org; Wed, 19 Nov 2003 10:54:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22975 for ; Wed, 19 Nov 2003 10:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUei-0001co-00 for rohc@ietf.org; Wed, 19 Nov 2003 10:54:12 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AMUeg-0001cl-00 for rohc@ietf.org; Wed, 19 Nov 2003 10:54:11 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAJFs9I2005029; Wed, 19 Nov 2003 16:54:09 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Nov 2003 16:54:09 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'West, Mark'" Cc: rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Wed, 19 Nov 2003 16:53:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , I agree with Mark that this is a new and rather controversial new requirement to introduce at this point, especially since we have already closed the issue several times. /L-E > Multiplexing is horrible (or, at the very least messy) > because you inherently bind the SigComp and SIP transport > handling for detecting the end of a message. If you don't > allow multiplexing, you are free to implement it this way (if > you want), but if you *do* allow multiplexing then this > becomes a requirement... > > But, like I say, I thought that the 'non-multiplexing' issue > had been agreed. And it's still not clear to me why it's > important to be able to do it! > > Cheers, > > Mark. > > > > > > -----Original Message----- > > From: Jan Christoffersson (LU/EAB) > > [mailto:jan.christoffersson@ericsson.com] > > Sent: 17 November 2003 13:47 > > To: West, Mark > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; rohc@ietf.org > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > > messages on > > t he same TCP connection > > > > > > Hi Mark, > > > > Comments inline. > > > > -----Original Message----- > > From: West, Mark [mailto:mark.a.west@roke.co.uk] > > Sent: den 14 november 2003 15:09 > > To: Jan Christoffersson (LU/EAB) > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; rohc@ietf.org > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > > messages on > > t he same TCP connection > > > > > > > > Hi Jan, > > > > Comments added! > > > > Cheers, > > > > Mark. > > > > > > > > 1. The extra delay caused by opening and closing TCP > > connections when > > > switching between SIP and SigComp should not be neglected. > > In some cases > > > it may be of little concern but in others it may be > > important. Reducing > > > delay has been the most important driving factor for SigComp. > > > Multiplexing over the same connection reduces the delay. > > > > > > > But most of the cases where you want to switch between SigComp / > > non-SigComp are inherently cases where there is inherent latency. > > > > [JC]I agree that these cases will probably have a lot of > > latency, so this argument isn't very heavy. Still, less > > latency is better. > > > > And RFC 3261 (if I read it correctly, but I'm no SIP guru), > > talks about > > only try to keep a transaction within in a single connection... > > > > > 2. We have the tools needed for multiplexing SigComp and > SIP on the > > > same TCP connection. Why not do it? It's faster than opening a new > > > connection. > > > > > > > But the 'tools' are horrible! Reiterating the sentiments > > from S-F: 'yeah, > > you could, but why would you want to..?' > > > > [JC]I don't know why this is so horrible? Could you please > > elaborate... > > > > > 3. Mark argues that if multiplexing is allowed, the > > receiver needs to > > > support it. But doesn't it already need to do this? As > > Zhigang pointed > > > out, RFC3486 states that > > > > > > "If a SIP client sends a compressed request and the client > > transaction > > > times out without having received any response, the > client SHOULD > > > retry the same request without using compression. If > > the compressed > > > request was sent over a TCP connection, the client > > SHOULD close that > > > connection and open a new one to send the uncompressed > request." > > > > > > In this text, it says SHOULD and not MUST, i.e. there could be > > > implementations that send SIP and SigComp on the same TCP > > connection, so > > > all implementations should be able to handle it. In any > > case, we have > > > delimiters to determine where SigComp messages start and > end, and if > > > there is something other than SigComp in between an end and > > a start, we > > > should be able to handle it. > > > > > > > That is slicing a semantic a shade too thin for me! But, if > > you want to > > play word games, then I'll point out that 'uncompressed' does > > not mean 'do > > not use SigComp'. > > [JC] I didn't intend this to be a word game. To me this is a > > recommendation to open a new TCP connection. I'm perfectly > > happy with that. But I don't think we should turn the > > recommendation into a must and forbid sending SigComp and > > non-SigComp on the same TCP connection. > > > > Carsten & I have whipped up a nice little 13-byte standard header: > > > > 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, > > 0x86, 0x01, 0x16, 0xf9, 0x23, ... > > > > that will simply output the following bytes! > > > > It's a SigComp message, but there's no compression... > > > > [JC]Yes, this is perfectly fine, unless the message is larger > > than 64 K. > > > > And let's not forget that the purpose of > > draft-ietf-rohc-sip-sigcomp is to > > fill in the missing pieces of the mapping jigsaw (i.e. the bits that > > aren't in RFC 3486). And that's what we're arguing about. > > (Although I > > was fairly sure that we'd already decided this. *sigh*) > > > > _______________________________________________ > 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 Nov 19 12:11:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27359 for ; Wed, 19 Nov 2003 12:11:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVr7-0000BM-0H for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 12:11:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHB4FF000693 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 12:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVr6-0000B5-Rq for rohc-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:11:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27285 for ; Wed, 19 Nov 2003 12:10:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVr5-0003aA-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 12:11:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVr5-0003a5-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 12:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVr5-0000Am-Nk; Wed, 19 Nov 2003 12:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVqp-00009t-I7 for rohc@optimus.ietf.org; Wed, 19 Nov 2003 12:10:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27274 for ; Wed, 19 Nov 2003 12:10:33 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVqo-0003Zb-00 for rohc@ietf.org; Wed, 19 Nov 2003 12:10:46 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMVqn-0003ZT-00 for rohc@ietf.org; Wed, 19 Nov 2003 12:10:45 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJHAh613650 for ; Wed, 19 Nov 2003 19:10:44 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 19:10:43 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 11:10:02 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] sigcomp-sip status Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Nov 2003 12:10:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8CB@ajebe001.americas.nokia.com> Thread-Topic: [rohc] sigcomp-sip status Thread-Index: AcOusX1gOnjJieDjR1+zMDtZRF71vAAAvcnQ To: , Cc: X-OriginalArrivalTime: 19 Nov 2003 17:10:02.0507 (UTC) FILETIME=[F858EDB0:01C3AEBF] 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 Mark, > So far as b) is concerned, I don't think that this is=20 > (necessarily) just an SMS issue (although it is a valid point).=20 > If I send 2 messages to the remote endpoint without receiving=20 > feedback, how do I know that the message has successfully=20 > arrived; been correctly decompressed; and that the SIP > application has authorised the state creation? If *any* of=20 > those are false, then I can't make use of the state, even if=20 > remote SMS is available. (Use of TCP makes the first likely,=20 > but doesn't impact the others...) Very valid question. I've actually gone through it too, but didn't spell it out to make my earlier email short. Now that=20 you correctly pointed them out, my answer is (a bit=20 surprisingly, or may be not): optimistic. Here is a simple example to show the idea. A B m1 ------>=20 m2 ------> <------- m3 When A sends the second message m2, it can optimistically assume m1 has survived the 3 conditions above, and use states uploaded=20 in m1 to compress m2. In most cases (if the compressor is=20 implemented correctly), the assumption should turn out true and=20 thus A enjoys the benefit. In the rare cases where it doesn't,=20 that means this is *already* a SigComp failure for *m1* which=20 requires a recovery procedure for m1. (Here we link to the multiplexing issue but I wouldn't deviate to that topic at this moment.)=20 So, being optimistic does not add additional penalty. Note that I've made one assumption in the above argument. That is, sending m3 is conditioned on the receiving of m1 and m2, in order.=20 This should be a reasonable assumption considering the nature of SIP signaling. Otherwise, that means=20 1) m3 depends only on one of {m1, m2}. In that case, why would A=20 bother send both messages at all in the first place? We want to reduce latency. 2) m3 depends on both {m1, m2}, but does not require them to be received in order. I cannot recall a real-life SIP example of this. But if it exists, there is indeed a penalty making m2 dependent on m1 *and* when a SigComp failure occurs on m1. Namely,=20 A has to resend m2 (in addition to m1), which is not needed=20 if A sent m1 and m2 independently in the first round. However, I don't see this is a big concern for two reasons: a) SigComp=20 failure should not be a frequent event, or we are in real trouble;=20 b) the delay caused by resending m2 is second order to the delay=20 caused by tear-down and reestablishment of same TCP connection, or establishment of a new TCP connection which may require setting up a new security association. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 19 13:13:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00851 for ; Wed, 19 Nov 2003 13:13:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWp4-0004z6-UN for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 13:13:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJID2ZF019154 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 13:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWp4-0004yr-RC for rohc-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 13:13:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00809 for ; Wed, 19 Nov 2003 13:12:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWp2-0005Vi-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 13:13:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWp2-0005Vf-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 13:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWp3-0004yZ-5r; Wed, 19 Nov 2003 13:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWof-0004xx-Go for rohc@optimus.ietf.org; Wed, 19 Nov 2003 13:12:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00772 for ; Wed, 19 Nov 2003 13:12:22 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWod-0005Ua-00 for rohc@ietf.org; Wed, 19 Nov 2003 13:12:35 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMWoc-0005UW-00 for rohc@ietf.org; Wed, 19 Nov 2003 13:12:34 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJICXA25550 for ; Wed, 19 Nov 2003 20:12:33 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 20:12:33 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 10:12:29 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Nov 2003 13:12:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8CC@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcOusjUV8fKCgAL9ShuPtzhdsyJ8gAADe4yQ To: , Cc: , X-OriginalArrivalTime: 19 Nov 2003 18:12:29.0668 (UTC) FILETIME=[B1D45240:01C3AEC8] 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, > And I agree that messages > 64kbyte are a problem=20 > with SigComp! =20 Is this a valid reason to have multiplexing over TCP?=20 Consider the scenario where the communication between endpoint A and B involves both delay sensitive short messages and=20 non-delay-sensitive long (> 64KB) messages. Without multiplexing, two TCP connections are required which leads to issues such as=20 synchronization of messages transmitted on the two TCP connections. =20 > Multiplexing is horrible (or, at the very least messy)=20 > because you inherently bind the SigComp and SIP transport=20 > handling for detecting the end of a message. =20 For a given TCP stream, multiplexing means the receiver needs to alternate between two parsing "modes": SigComp mode, in which SigComp controls the parsing of incoming stream, and transparent mode, in which the application takes control.=20 This passing of "controls" between SigComp and application does=20 add complexity. But is it really "horrible" or "messy", considering the binding/interaction between SigComp and application we already have, such as message authentication, compartment management,=20 feedback, etc?=20 > If you don't allow multiplexing, you are free to implement it=20 > this way (if you want),=20 Not really. The sender has to know if the receiver supports=20 multiplexing. So, it's not just a matter of implementation. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 19 14:24:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05089 for ; Wed, 19 Nov 2003 14:24:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXvm-00016N-6R for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 14:24:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJJO2rv004229 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 14:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXvm-000168-2g for rohc-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 14:24:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05054 for ; Wed, 19 Nov 2003 14:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXvj-0007fr-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 14:23:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMXvi-0007fo-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 14:23:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXvk-00015t-N3; Wed, 19 Nov 2003 14:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXvW-00015h-Qf for rohc@optimus.ietf.org; Wed, 19 Nov 2003 14:23:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05043 for ; Wed, 19 Nov 2003 14:23:32 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXvU-0007fW-00 for rohc@ietf.org; Wed, 19 Nov 2003 14:23:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMXvT-0007fS-00 for rohc@ietf.org; Wed, 19 Nov 2003 14:23:43 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJJNh629203 for ; Wed, 19 Nov 2003 21:23:43 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Nov 2003 21:23:42 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 13:23:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Nov 2003 13:23:33 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139891D@daebe004.americas.nokia.com> Thread-Topic: [rohc] SigComp implementer's guide status Thread-Index: AcOjibe1pAnS7ahnQNeaCOjh4Qj3PQLRwOSQ To: X-OriginalArrivalTime: 19 Nov 2003 19:23:33.0386 (UTC) FILETIME=[9F340EA0:01C3AED2] Content-Transfer-Encoding: quoted-printable Subject: [rohc] IP Address Compression for Context Replication Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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 Hello, The current Context Replication mechanism suggests to send either whole = IP address or no IP address (replication). We have submitted a draft on = the idea of sending compressed IP address using base IP address. This = improves header compression efficiency when packet flows carry similar = (e.g. same prefix) but not exactly same IP addresses. In particular, the = gain can be significant for IPv6 header compression due to the large = size (16 bytes) of IPv6 addresses. =20 http://www.ietf.org/internet-drafts/draft-saifullah-rohc-ip-addr-comp-con= text-replication-00.txt This draft has impacts on section 6.5.5.1 of draft-ietf-rohc-tcp-05.txt, = where the format of src/dest IP addresses are defined for IR-CR. Your comments and questions on this draft are more than welcome. Regards, Yousuf _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Nov 19 16:02:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11495 for ; Wed, 19 Nov 2003 16:02:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZSd-00085C-7n for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 16:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJL239Y031070 for rohc-archive@odin.ietf.org; Wed, 19 Nov 2003 16:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZSd-000853-4S for rohc-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 16:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11488 for ; Wed, 19 Nov 2003 16:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZSb-00027U-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 16:02:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMZSb-00027R-00 for rohc-web-archive@ietf.org; Wed, 19 Nov 2003 16:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZSb-00084o-PL; Wed, 19 Nov 2003 16:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZSJ-00083r-W8 for rohc@optimus.ietf.org; Wed, 19 Nov 2003 16:01:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11481 for ; Wed, 19 Nov 2003 16:01:30 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZSI-00027I-00 for rohc@ietf.org; Wed, 19 Nov 2003 16:01:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMZSH-00027F-00 for rohc@ietf.org; Wed, 19 Nov 2003 16:01:41 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJL1fA12152 for ; Wed, 19 Nov 2003 23:01:41 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 23:01:40 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 13:01:36 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Nov 2003 16:01:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E8CD@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcOutYT6smHCEhI1Q4GLHKoASggzUwAJtngA To: , Cc: X-OriginalArrivalTime: 19 Nov 2003 21:01:36.0967 (UTC) FILETIME=[52174570:01C3AEE0] 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, If I remember correctly, what has been closed/clarified was that=20 RFC 3320 does not allow multiplexing.=20 However, the issue here is whether or not the multiplexing is needed.=20 Obviously, people already have their own opinions in mind. But until recently, there haven't been many technical discussions regarding=20 this issue on ROHC mailing list. So, I'm not sure what do you mean by "we have already closed the issue several times"? Or did I miss anything? Either way, what I'd like to see is a serious debate on this issue from different aspects, so that in the end, we can say with confidence that we've taken a hard look on the issue and here is our conclusion. BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Lars-Erik Jonsson (LU/EAB) > Sent: November 19, 2003 09:54 AM > To: 'West, Mark' > Cc: rohc@ietf.org > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp=20 > messages on > t he same TCP connection >=20 >=20 > I agree with Mark that this is a new and rather controversial > new requirement to introduce at this point, especially since > we have already closed the issue several times. >=20 > /L-E >=20 >=20 > > Multiplexing is horrible (or, at the very least messy)=20 > > because you inherently bind the SigComp and SIP transport=20 > > handling for detecting the end of a message. If you don't=20 > > allow multiplexing, you are free to implement it this way (if=20 > > you want), but if you *do* allow multiplexing then this=20 > > becomes a requirement... > >=20 > > But, like I say, I thought that the 'non-multiplexing' issue=20 > > had been agreed. And it's still not clear to me why it's=20 > > important to be able to do it! > >=20 > > Cheers, > >=20 > > Mark. > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Jan Christoffersson (LU/EAB) > > > [mailto:jan.christoffersson@ericsson.com] > > > Sent: 17 November 2003 13:47 > > > To: West, Mark > > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; rohc@ietf.org > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp=20 > > > messages on > > > t he same TCP connection > > >=20 > > >=20 > > > Hi Mark, > > >=20 > > > Comments inline. > > >=20 > > > -----Original Message----- > > > From: West, Mark [mailto:mark.a.west@roke.co.uk] > > > Sent: den 14 november 2003 15:09 > > > To: Jan Christoffersson (LU/EAB) > > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; rohc@ietf.org > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp=20 > > > messages on > > > t he same TCP connection > > >=20 > > >=20 > > >=20 > > > Hi Jan, > > >=20 > > > Comments added! > > >=20 > > > Cheers, > > >=20 > > > Mark. > > >=20 > > > > > > > > 1. The extra delay caused by opening and closing TCP=20 > > > connections when > > > > switching between SIP and SigComp should not be neglected.=20 > > > In some cases > > > > it may be of little concern but in others it may be=20 > > > important. Reducing > > > > delay has been the most important driving factor for SigComp. > > > > Multiplexing over the same connection reduces the delay. > > > > > > >=20 > > > But most of the cases where you want to switch between SigComp / > > > non-SigComp are inherently cases where there is inherent latency. > > >=20 > > > [JC]I agree that these cases will probably have a lot of=20 > > > latency, so this argument isn't very heavy. Still, less=20 > > > latency is better. > > >=20 > > > And RFC 3261 (if I read it correctly, but I'm no SIP guru),=20 > > > talks about > > > only try to keep a transaction within in a single connection... > > >=20 > > > > 2. We have the tools needed for multiplexing SigComp and=20 > > SIP on the > > > > same TCP connection. Why not do it? It's faster than=20 > opening a new > > > > connection. > > > > > > >=20 > > > But the 'tools' are horrible! Reiterating the sentiments=20 > > > from S-F: 'yeah, > > > you could, but why would you want to..?' > > >=20 > > > [JC]I don't know why this is so horrible? Could you please=20 > > > elaborate... > > >=20 > > > > 3. Mark argues that if multiplexing is allowed, the=20 > > > receiver needs to > > > > support it. But doesn't it already need to do this? As=20 > > > Zhigang pointed > > > > out, RFC3486 states that > > > > > > > > "If a SIP client sends a compressed request and the client=20 > > > transaction > > > > times out without having received any response, the=20 > > client SHOULD > > > > retry the same request without using compression. If=20 > > > the compressed > > > > request was sent over a TCP connection, the client=20 > > > SHOULD close that > > > > connection and open a new one to send the uncompressed=20 > > request." > > > > > > > > In this text, it says SHOULD and not MUST, i.e. there could be > > > > implementations that send SIP and SigComp on the same TCP=20 > > > connection, so > > > > all implementations should be able to handle it. In any=20 > > > case, we have > > > > delimiters to determine where SigComp messages start and=20 > > end, and if > > > > there is something other than SigComp in between an end and=20 > > > a start, we > > > > should be able to handle it. > > > > > > >=20 > > > That is slicing a semantic a shade too thin for me! But, if=20 > > > you want to > > > play word games, then I'll point out that 'uncompressed' does=20 > > > not mean 'do > > > not use SigComp'. > > > [JC] I didn't intend this to be a word game. To me this is a=20 > > > recommendation to open a new TCP connection. I'm perfectly=20 > > > happy with that. But I don't think we should turn the=20 > > > recommendation into a must and forbid sending SigComp and=20 > > > non-SigComp on the same TCP connection. > > >=20 > > > Carsten & I have whipped up a nice little 13-byte standard header: > > >=20 > > > 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, > > > 0x86, 0x01, 0x16, 0xf9, 0x23, ... > > >=20 > > > that will simply output the following bytes! > > >=20 > > > It's a SigComp message, but there's no compression... > > >=20 > > > [JC]Yes, this is perfectly fine, unless the message is larger=20 > > > than 64 K.=20 > > >=20 > > > And let's not forget that the purpose of=20 > > > draft-ietf-rohc-sip-sigcomp is to > > > fill in the missing pieces of the mapping jigsaw (i.e.=20 > the bits that > > > aren't in RFC 3486). And that's what we're arguing about. =20 > > > (Although I > > > was fairly sure that we'd already decided this. *sigh*) > > >=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 20 09:58:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07097 for ; Thu, 20 Nov 2003 09:58:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqFu-00005S-Bf for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 09:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEw2lk000328 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 09:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqFu-00005D-7t for rohc-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07069 for ; Thu, 20 Nov 2003 09:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqFs-0004F1-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 09:58:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMqFr-0004Ey-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 09:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqFs-00004v-Vf; Thu, 20 Nov 2003 09:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqFV-0008W9-Qz for rohc@optimus.ietf.org; Thu, 20 Nov 2003 09:57:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07065 for ; Thu, 20 Nov 2003 09:57:23 -0500 (EST) From: Robert.Sugar@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqFT-0004Er-00 for rohc@ietf.org; Thu, 20 Nov 2003 09:57:35 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMqFT-0004Em-00 for rohc@ietf.org; Thu, 20 Nov 2003 09:57:35 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAKEvXA01235 for ; Thu, 20 Nov 2003 16:57:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 16:57:32 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 16:57:33 +0200 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 16:57:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Thu, 20 Nov 2003 15:57:30 +0100 Message-ID: <21B200DF0688CC45ACF38F49D2279832013396F2@buebe002.europe.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcOutYT6smHCEhI1Q4GLHKoASggzUwAJtngAACQYMsA= To: , , Cc: X-OriginalArrivalTime: 20 Nov 2003 14:57:32.0824 (UTC) FILETIME=[A0615180:01C3AF76] 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 all, Let me give some more facets to the discussion: Many times the latency is not just the TCP handshake, but has other = contributors as well. In case of IPSec, there is no abundance of TCP = connection possibilities, those are limited to at most the number of SAs = available. And in order to set up a new SA, the use of an additional = protocol (e.g. IKE, or RFC3310) is needed. So it is not only the new TCP = setup delay, but also the SA setup delay. In case of TLS the handshake = costs quite a few messages too. Besides the >64K messages, and general SigComp errors, RFC3486 is the = other reason to have SigComp and non-SigComp messages multiplexed (at = least in time). Endpoints have the possibility to indicate willingness = for receiving SigComp messages on a per transaction basis (for example a = CPU-challenged endpoint wants to compress delay-sensitive session = setups, but not instant messages). We should not burden that choice with = significant additional delay, because that would take away useful = functionalites from RFC3486. In many protocols (HTTP being one of them), TCP connection close has = also application level meanings, thus opening a new connection may cause = application level delays as well as a different user experience or = protocol behavior. BR, Robert =20 > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > zhigang.c.liu@nokia.com > Sent: November 19,2003 22:01 > To: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk > Cc: rohc@ietf.org > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp=20 > messages on > t he same TCP connection >=20 >=20 > Hi, >=20 > If I remember correctly, what has been closed/clarified was that=20 > RFC 3320 does not allow multiplexing.=20 >=20 > However, the issue here is whether or not the multiplexing is needed.=20 > Obviously, people already have their own opinions in mind. But until > recently, there haven't been many technical discussions regarding=20 > this issue on ROHC mailing list. So, I'm not sure what do you mean > by "we have already closed the issue several times"? Or did I miss > anything? >=20 > Either way, what I'd like to see is a serious debate on this issue > from different aspects, so that in the end, we can say with confidence > that we've taken a hard look on the issue and here is our conclusion. >=20 > BR, > Zhigang >=20 > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On=20 > Behalf Of ext > > Lars-Erik Jonsson (LU/EAB) > > Sent: November 19, 2003 09:54 AM > > To: 'West, Mark' > > Cc: rohc@ietf.org > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp=20 > > messages on > > t he same TCP connection > >=20 > >=20 > > I agree with Mark that this is a new and rather controversial > > new requirement to introduce at this point, especially since > > we have already closed the issue several times. > >=20 > > /L-E > >=20 > >=20 > > > Multiplexing is horrible (or, at the very least messy)=20 > > > because you inherently bind the SigComp and SIP transport=20 > > > handling for detecting the end of a message. If you don't=20 > > > allow multiplexing, you are free to implement it this way (if=20 > > > you want), but if you *do* allow multiplexing then this=20 > > > becomes a requirement... > > >=20 > > > But, like I say, I thought that the 'non-multiplexing' issue=20 > > > had been agreed. And it's still not clear to me why it's=20 > > > important to be able to do it! > > >=20 > > > Cheers, > > >=20 > > > Mark. > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Jan Christoffersson (LU/EAB) > > > > [mailto:jan.christoffersson@ericsson.com] > > > > Sent: 17 November 2003 13:47 > > > > To: West, Mark > > > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com;=20 > rohc@ietf.org > > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp=20 > > > > messages on > > > > t he same TCP connection > > > >=20 > > > >=20 > > > > Hi Mark, > > > >=20 > > > > Comments inline. > > > >=20 > > > > -----Original Message----- > > > > From: West, Mark [mailto:mark.a.west@roke.co.uk] > > > > Sent: den 14 november 2003 15:09 > > > > To: Jan Christoffersson (LU/EAB) > > > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com;=20 > rohc@ietf.org > > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp=20 > > > > messages on > > > > t he same TCP connection > > > >=20 > > > >=20 > > > >=20 > > > > Hi Jan, > > > >=20 > > > > Comments added! > > > >=20 > > > > Cheers, > > > >=20 > > > > Mark. > > > >=20 > > > > > > > > > > 1. The extra delay caused by opening and closing TCP=20 > > > > connections when > > > > > switching between SIP and SigComp should not be neglected.=20 > > > > In some cases > > > > > it may be of little concern but in others it may be=20 > > > > important. Reducing > > > > > delay has been the most important driving factor for SigComp. > > > > > Multiplexing over the same connection reduces the delay. > > > > > > > > >=20 > > > > But most of the cases where you want to switch between SigComp / > > > > non-SigComp are inherently cases where there is=20 > inherent latency. > > > >=20 > > > > [JC]I agree that these cases will probably have a lot of=20 > > > > latency, so this argument isn't very heavy. Still, less=20 > > > > latency is better. > > > >=20 > > > > And RFC 3261 (if I read it correctly, but I'm no SIP guru),=20 > > > > talks about > > > > only try to keep a transaction within in a single connection... > > > >=20 > > > > > 2. We have the tools needed for multiplexing SigComp and=20 > > > SIP on the > > > > > same TCP connection. Why not do it? It's faster than=20 > > opening a new > > > > > connection. > > > > > > > > >=20 > > > > But the 'tools' are horrible! Reiterating the sentiments=20 > > > > from S-F: 'yeah, > > > > you could, but why would you want to..?' > > > >=20 > > > > [JC]I don't know why this is so horrible? Could you please=20 > > > > elaborate... > > > >=20 > > > > > 3. Mark argues that if multiplexing is allowed, the=20 > > > > receiver needs to > > > > > support it. But doesn't it already need to do this? As=20 > > > > Zhigang pointed > > > > > out, RFC3486 states that > > > > > > > > > > "If a SIP client sends a compressed request and the client=20 > > > > transaction > > > > > times out without having received any response, the=20 > > > client SHOULD > > > > > retry the same request without using compression. If=20 > > > > the compressed > > > > > request was sent over a TCP connection, the client=20 > > > > SHOULD close that > > > > > connection and open a new one to send the uncompressed=20 > > > request." > > > > > > > > > > In this text, it says SHOULD and not MUST, i.e. there could be > > > > > implementations that send SIP and SigComp on the same TCP=20 > > > > connection, so > > > > > all implementations should be able to handle it. In any=20 > > > > case, we have > > > > > delimiters to determine where SigComp messages start and=20 > > > end, and if > > > > > there is something other than SigComp in between an end and=20 > > > > a start, we > > > > > should be able to handle it. > > > > > > > > >=20 > > > > That is slicing a semantic a shade too thin for me! But, if=20 > > > > you want to > > > > play word games, then I'll point out that 'uncompressed' does=20 > > > > not mean 'do > > > > not use SigComp'. > > > > [JC] I didn't intend this to be a word game. To me this is a=20 > > > > recommendation to open a new TCP connection. I'm perfectly=20 > > > > happy with that. But I don't think we should turn the=20 > > > > recommendation into a must and forbid sending SigComp and=20 > > > > non-SigComp on the same TCP connection. > > > >=20 > > > > Carsten & I have whipped up a nice little 13-byte=20 > standard header: > > > >=20 > > > > 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, > > > > 0x86, 0x01, 0x16, 0xf9, 0x23, ... > > > >=20 > > > > that will simply output the following bytes! > > > >=20 > > > > It's a SigComp message, but there's no compression... > > > >=20 > > > > [JC]Yes, this is perfectly fine, unless the message is larger=20 > > > > than 64 K.=20 > > > >=20 > > > > And let's not forget that the purpose of=20 > > > > draft-ietf-rohc-sip-sigcomp is to > > > > fill in the missing pieces of the mapping jigsaw (i.e.=20 > > the bits that > > > > aren't in RFC 3486). And that's what we're arguing about. =20 > > > > (Although I > > > > was fairly sure that we'd already decided this. *sigh*) > > > >=20 > > >=20 > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > >=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 20 09:59:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07127 for ; Thu, 20 Nov 2003 09:59:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqGr-00009L-KN for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 09:59:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEx1mI000569 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqGr-000096-Gc for rohc-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:59:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07113 for ; Thu, 20 Nov 2003 09:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqGp-0004FV-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 09:58:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMqGp-0004FS-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 09:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqGq-00007v-GN; Thu, 20 Nov 2003 09:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqG2-00007R-D4 for rohc@optimus.ietf.org; Thu, 20 Nov 2003 09:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07073 for ; Thu, 20 Nov 2003 09:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqFy-0004F6-00 for rohc@ietf.org; Thu, 20 Nov 2003 09:58:06 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AMqFy-0004Eo-00 for rohc@ietf.org; Thu, 20 Nov 2003 09:58:06 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 14:57:34 -0000 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPYKQ; Thu, 20 Nov 2003 14:57:29 -0000 From: "West, Mark" To: Yousuf.Saifullah@nokia.com Cc: rohc@ietf.org Date: Thu, 20 Nov 2003 16:07:56 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: Re: [rohc] IP Address Compression for Context Replication In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE0139891D@daebe004.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Yousuf, I'm not sure how often you would set up a temporally close sequence of short-lived connections to different machines on the same subnet (web-server load balancing, perhaps? but I thought that this was often hidden from the user...) Do you have any views on this..? However, more seriously, I note that the draft has an IPR statement :-( We are trying to make the TCP compression solution as generally useful as possible and so the inclusion of an encumbered concept is something that I, personally, would object to. Can you clarify this position? As a final comment, I'm not sure how helpful the appendix is, since classless routing has been used since (at least) RFCs 1517/18/19... (... and site-local addresses in IPv6 are now deprecated ;-) Cheers, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 On Wed, 19 Nov 2003 Yousuf.Saifullah@nokia.com wrote: > Date: Wed, 19 Nov 2003 13:23:33 -0600 > From: Yousuf.Saifullah@nokia.com > To: rohc@ietf.org > Subject: [rohc] IP Address Compression for Context Replication > > Hello, > The current Context Replication mechanism suggests to send either whole IP address or no IP address (replication). We have submitted a draft on the idea of sending compressed IP address using base IP address. This improves header compression efficiency when packet flows carry similar (e.g. same prefix) but not exactly same IP addresses. In particular, the gain can be significant for IPv6 header compression due to the large size (16 bytes) of IPv6 addresses. > > http://www.ietf.org/internet-drafts/draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt > > This draft has impacts on section 6.5.5.1 of draft-ietf-rohc-tcp-05.txt, where the format of src/dest IP addresses are defined for IR-CR. > > Your comments and questions on this draft are more than welcome. > > Regards, > Yousuf > > > _______________________________________________ > 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 Nov 20 15:30:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24205 for ; Thu, 20 Nov 2003 15:30:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvRG-00083Z-04 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 15:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKU5Gj030960 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 15:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvRF-000837-RD for rohc-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24181 for ; Thu, 20 Nov 2003 15:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvRE-0001od-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 15:30:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMvRE-0001oZ-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 15:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvRC-00081U-S7; Thu, 20 Nov 2003 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvQl-00080p-RA for rohc@optimus.ietf.org; Thu, 20 Nov 2003 15:29:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24150; Thu, 20 Nov 2003 15:29:22 -0500 (EST) Message-Id: <200311202029.PAA24150@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: Thu, 20 Nov 2003 15:29:22 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sctp-requirements-03.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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/SCTP Robust Header Compression Author(s) : C. Schmidt, M. Tuexen Filename : draft-ietf-rohc-sctp-requirements-03.txt Pages : 13 Date : 2003-11-20 This document contains requirements for the IP/SCTP header compression scheme (profile) to be developed by the ROHC WG. The structure of this document is inherited from the document defining IP/TCP requirements for ROHC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sctp-requirements-03.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-sctp-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sctp-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-20154504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sctp-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sctp-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20154504.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 20 17:30:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03500 for ; Thu, 20 Nov 2003 17:30:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxJM-0001qe-3i for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 17:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMU4v2007098 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 17:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxJL-0001qP-V5 for rohc-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 17:30:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03485 for ; Thu, 20 Nov 2003 17:29:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxJJ-0005Po-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 17:30:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMxJI-0005Pj-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 17:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxJK-0001pn-78; Thu, 20 Nov 2003 17:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxIY-0001og-Oh for rohc@optimus.ietf.org; Thu, 20 Nov 2003 17:29:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03461 for ; Thu, 20 Nov 2003 17:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxIW-0005Op-00 for rohc@ietf.org; Thu, 20 Nov 2003 17:29:12 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AMxIV-0005O5-00 for rohc@ietf.org; Thu, 20 Nov 2003 17:29:11 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 22:28:35 -0000 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V0VRPYY1; Thu, 20 Nov 2003 22:28:29 -0000 From: "West, Mark" To: Robert.Sugar@nokia.com Cc: zhigang.c.liu@nokia.com, lars-erik.jonsson@ericsson.com, rohc@ietf.org Date: Thu, 20 Nov 2003 22:28:28 +0000 (GMT Standard Time) Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection In-Reply-To: <21B200DF0688CC45ACF38F49D2279832013396F2@buebe002.europe.nokia.com> Message-ID: References: <21B200DF0688CC45ACF38F49D2279832013396F2@buebe002.europe.nokia.com> X-X-Sender: maw1@maw-laptop.roke.co.uk 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: , Hi all, If you want a different take on this question, how about this... We seem to be addressing 2 questions: (1) is multiplexing of SigComp / non-SigComp messages over TCP *generally* useful; (2) is this useful in a constrained environment with an IPsec SA between peers..? Considering (2), something that has not yet been raised is the use of what is sometimes referred to as 'continuous mode'. The state model in RFC 3320 exists for 2 reasons: lack of security between end-points; and (potential) lack of reliability. The IPsec SA and use of TCP renders both of these non-issues. So, why not have a persistent UDVM..? This is perfectly reasonable within RFC 3320 -- there is no need for state-storage, as the UDVM is simply kept running. Since, in this model, there is no need to align SIP messages with SigComp boundaries, the 64kbyte limit need not apply: SigComp ends up simply providing a compressed TCP stream... ... so connection close semantics are preserved... Failures essentially become desynchronisation problems (as could occur with regular SIP), requiring reset of the TCP connection. The sending of low processing cost messages can still be supported by using the header that was suggested earlier (with the decompressor explicitly looking for this). And no need for multiplexing..! ;-) Cheers, Mark. On Thu, 20 Nov 2003 Robert.Sugar@nokia.com wrote: > Date: Thu, 20 Nov 2003 15:57:30 +0100 > From: Robert.Sugar@nokia.com > To: zhigang.c.liu@nokia.com, lars-erik.jonsson@ericsson.com, > mark.a.west@roke.co.uk > Cc: rohc@ietf.org > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on > t he same TCP connection > > Hi all, > > Let me give some more facets to the discussion: > > Many times the latency is not just the TCP handshake, but has other contributors as well. In case of IPSec, there is no abundance of TCP connection possibilities, those are limited to at most the number of SAs available. And in order to set up a new SA, the use of an additional protocol (e.g. IKE, or RFC3310) is needed. So it is not only the new TCP setup delay, but also the SA setup delay. In case of TLS the handshake costs quite a few messages too. > > Besides the >64K messages, and general SigComp errors, RFC3486 is the other reason to have SigComp and non-SigComp messages multiplexed (at least in time). Endpoints have the possibility to indicate willingness for receiving SigComp messages on a per transaction basis (for example a CPU-challenged endpoint wants to compress delay-sensitive session setups, but not instant messages). We should not burden that choice with significant additional delay, because that would take away useful functionalites from RFC3486. > > In many protocols (HTTP being one of them), TCP connection close has also application level meanings, thus opening a new connection may cause application level delays as well as a different user experience or protocol behavior. > > BR, > Robert > > > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > > zhigang.c.liu@nokia.com > > Sent: November 19,2003 22:01 > > To: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk > > Cc: rohc@ietf.org > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > > messages on > > t he same TCP connection > > > > > > Hi, > > > > If I remember correctly, what has been closed/clarified was that > > RFC 3320 does not allow multiplexing. > > > > However, the issue here is whether or not the multiplexing is needed. > > Obviously, people already have their own opinions in mind. But until > > recently, there haven't been many technical discussions regarding > > this issue on ROHC mailing list. So, I'm not sure what do you mean > > by "we have already closed the issue several times"? Or did I miss > > anything? > > > > Either way, what I'd like to see is a serious debate on this issue > > from different aspects, so that in the end, we can say with confidence > > that we've taken a hard look on the issue and here is our conclusion. > > > > BR, > > Zhigang > > > > > -----Original Message----- > > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On > > Behalf Of ext > > > Lars-Erik Jonsson (LU/EAB) > > > Sent: November 19, 2003 09:54 AM > > > To: 'West, Mark' > > > Cc: rohc@ietf.org > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > > > messages on > > > t he same TCP connection > > > > > > > > > I agree with Mark that this is a new and rather controversial > > > new requirement to introduce at this point, especially since > > > we have already closed the issue several times. > > > > > > /L-E > > > > > > > > > > Multiplexing is horrible (or, at the very least messy) > > > > because you inherently bind the SigComp and SIP transport > > > > handling for detecting the end of a message. If you don't > > > > allow multiplexing, you are free to implement it this way (if > > > > you want), but if you *do* allow multiplexing then this > > > > becomes a requirement... > > > > > > > > But, like I say, I thought that the 'non-multiplexing' issue > > > > had been agreed. And it's still not clear to me why it's > > > > important to be able to do it! > > > > > > > > Cheers, > > > > > > > > Mark. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jan Christoffersson (LU/EAB) > > > > > [mailto:jan.christoffersson@ericsson.com] > > > > > Sent: 17 November 2003 13:47 > > > > > To: West, Mark > > > > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; > > rohc@ietf.org > > > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > > > > > messages on > > > > > t he same TCP connection > > > > > > > > > > > > > > > Hi Mark, > > > > > > > > > > Comments inline. > > > > > > > > > > -----Original Message----- > > > > > From: West, Mark [mailto:mark.a.west@roke.co.uk] > > > > > Sent: den 14 november 2003 15:09 > > > > > To: Jan Christoffersson (LU/EAB) > > > > > Cc: zhigang.c.liu@nokia.com; Robert.Sugar@nokia.com; > > rohc@ietf.org > > > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp > > > > > messages on > > > > > t he same TCP connection > > > > > > > > > > > > > > > > > > > > Hi Jan, > > > > > > > > > > Comments added! > > > > > > > > > > Cheers, > > > > > > > > > > Mark. > > > > > > > > > > > > > > > > > 1. The extra delay caused by opening and closing TCP > > > > > connections when > > > > > > switching between SIP and SigComp should not be neglected. > > > > > In some cases > > > > > > it may be of little concern but in others it may be > > > > > important. Reducing > > > > > > delay has been the most important driving factor for SigComp. > > > > > > Multiplexing over the same connection reduces the delay. > > > > > > > > > > > > > > > > But most of the cases where you want to switch between SigComp / > > > > > non-SigComp are inherently cases where there is > > inherent latency. > > > > > > > > > > [JC]I agree that these cases will probably have a lot of > > > > > latency, so this argument isn't very heavy. Still, less > > > > > latency is better. > > > > > > > > > > And RFC 3261 (if I read it correctly, but I'm no SIP guru), > > > > > talks about > > > > > only try to keep a transaction within in a single connection... > > > > > > > > > > > 2. We have the tools needed for multiplexing SigComp and > > > > SIP on the > > > > > > same TCP connection. Why not do it? It's faster than > > > opening a new > > > > > > connection. > > > > > > > > > > > > > > > > But the 'tools' are horrible! Reiterating the sentiments > > > > > from S-F: 'yeah, > > > > > you could, but why would you want to..?' > > > > > > > > > > [JC]I don't know why this is so horrible? Could you please > > > > > elaborate... > > > > > > > > > > > 3. Mark argues that if multiplexing is allowed, the > > > > > receiver needs to > > > > > > support it. But doesn't it already need to do this? As > > > > > Zhigang pointed > > > > > > out, RFC3486 states that > > > > > > > > > > > > "If a SIP client sends a compressed request and the client > > > > > transaction > > > > > > times out without having received any response, the > > > > client SHOULD > > > > > > retry the same request without using compression. If > > > > > the compressed > > > > > > request was sent over a TCP connection, the client > > > > > SHOULD close that > > > > > > connection and open a new one to send the uncompressed > > > > request." > > > > > > > > > > > > In this text, it says SHOULD and not MUST, i.e. there could be > > > > > > implementations that send SIP and SigComp on the same TCP > > > > > connection, so > > > > > > all implementations should be able to handle it. In any > > > > > case, we have > > > > > > delimiters to determine where SigComp messages start and > > > > end, and if > > > > > > there is something other than SigComp in between an end and > > > > > a start, we > > > > > > should be able to handle it. > > > > > > > > > > > > > > > > That is slicing a semantic a shade too thin for me! But, if > > > > > you want to > > > > > play word games, then I'll point out that 'uncompressed' does > > > > > not mean 'do > > > > > not use SigComp'. > > > > > [JC] I didn't intend this to be a word game. To me this is a > > > > > recommendation to open a new TCP connection. I'm perfectly > > > > > happy with that. But I don't think we should turn the > > > > > recommendation into a must and forbid sending SigComp and > > > > > non-SigComp on the same TCP connection. > > > > > > > > > > Carsten & I have whipped up a nice little 13-byte > > standard header: > > > > > > > > > > 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, > > > > > 0x86, 0x01, 0x16, 0xf9, 0x23, ... > > > > > > > > > > that will simply output the following bytes! > > > > > > > > > > It's a SigComp message, but there's no compression... > > > > > > > > > > [JC]Yes, this is perfectly fine, unless the message is larger > > > > > than 64 K. > > > > > > > > > > And let's not forget that the purpose of > > > > > draft-ietf-rohc-sip-sigcomp is to > > > > > fill in the missing pieces of the mapping jigsaw (i.e. > > > the bits that > > > > > aren't in RFC 3486). And that's what we're arguing about. > > > > > (Although I > > > > > was fairly sure that we'd already decided this. *sigh*) > > > > > > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 20 20:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13549 for ; Thu, 20 Nov 2003 20:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0Wh-0005od-95 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 20:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL1u3MJ022343 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 20:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0Wh-0005oI-48 for rohc-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 20:56:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13538 for ; Thu, 20 Nov 2003 20:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0We-0001Lv-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 20:56:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN0We-0001Ls-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 20:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0Wf-0005lS-Mq; Thu, 20 Nov 2003 20:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0W3-0005kh-R2 for rohc@optimus.ietf.org; Thu, 20 Nov 2003 20:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13527 for ; Thu, 20 Nov 2003 20:55:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0W1-0001Lf-00 for rohc@ietf.org; Thu, 20 Nov 2003 20:55:21 -0500 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1AN0Vw-0001Lc-00 for rohc@ietf.org; Thu, 20 Nov 2003 20:55:21 -0500 Received: from qibaojian (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HOO00DDRIB0LD@mta1.huawei.com> for rohc@ietf.org; Fri, 21 Nov 2003 09:47:25 +0800 (CST) Date: Fri, 21 Nov 2003 09:54:21 +0800 From: qibaojian To: rohc@ietf.org Message-id: <00a901c3afd2$61dfdd80$4104460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_uA82q0zEu/0UOnu1U0KtUA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] Question about the compress scheme to compress the RTP/UDP/IP/PPP headers Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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 multi-part message in MIME format. --Boundary_(ID_uA82q0zEu/0UOnu1U0KtUA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi Is the compress scheme to compress the RTP/UDP/IP/PPP headers unitedly exist? qibaojian --Boundary_(ID_uA82q0zEu/0UOnu1U0KtUA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi
 
Is the compress scheme to compress the RTP/UDP/IP/PPP headers unitedly exist?
 
qibaojian
--Boundary_(ID_uA82q0zEu/0UOnu1U0KtUA)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Nov 20 21:16:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13998 for ; Thu, 20 Nov 2003 21:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0q3-0006ua-1A for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 21:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL2G2cI026534 for rohc-archive@odin.ietf.org; Thu, 20 Nov 2003 21:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0q2-0006tt-R8 for rohc-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 21:16:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13992 for ; Thu, 20 Nov 2003 21:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0pz-0001ZC-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 21:15:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN0pz-0001Z9-00 for rohc-web-archive@ietf.org; Thu, 20 Nov 2003 21:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0q1-0006sX-3l; Thu, 20 Nov 2003 21:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0pS-0006rG-Eo for rohc@optimus.ietf.org; Thu, 20 Nov 2003 21:15:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13977 for ; Thu, 20 Nov 2003 21:15:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0pP-0001Yh-00 for rohc@ietf.org; Thu, 20 Nov 2003 21:15:23 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AN0pP-0001YY-00 for rohc@ietf.org; Thu, 20 Nov 2003 21:15:23 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hAL2FG4t018477 for ; Thu, 20 Nov 2003 18:15:17 -0800 (PST) Received: from HAIPENGJ.qualcomm.com (haipengj.qualcomm.com [129.46.74.180]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hAL2FFU0027454 for ; Thu, 20 Nov 2003 18:15:15 -0800 (PST) Message-Id: <5.2.0.9.2.20031120173540.00b43380@E2k.qualcomm.com> X-Sender: haipengj@E2k.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Nov 2003 18:15:15 -0800 To: "Rohc (E-mail)" From: Haipeng Jin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rohc] Question about scaled TS encoding in ROHC RTP Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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, In ROHC RTP, the scaled TS is encoded using WLSB algorithm. Since the wraparound boundary between the TSS_MAX may not correspond to a natural boundary between LSBs, a number of unused values are inserted into it after TSS_MAX such that their LSBs follow naturally upon each other. In order to ensure the number of valid values in the interpretation interval to be high enough to maintain robustness, a scaling rule (RFC3095, 4.5.3) is used to increase the number of bits actually sent at wraparound. Here comes my question: What kind of robustness does the RFC actually refer to by maintaining a large number of valid values in the interpretation interval? It seems to me that if there are no errors in the bits transmitted in the compressed header, then the TS will be decoded correctly no matter how many invalid values are in the interval. If there are errors in the transmitted bits, then the decompressed TS will always be in error no matter how few the number of invalid values in the interval is, an erroneous TS is an erroneous TS, no matter it is a valid value or invalid value in the interval. Can anyone could please explain the reasoning behind the scaling rule? Actually, I also notice that if the scaling rule is used, there may actually be some problem when there are negative wraparounds. Here is an example, suppose tss_max = 0x0333, reference value vr = 0, the value to be coded v = 0x0333, p = 2^(k-2)-1 according to ROHC. First, LSB encoding: k p interval interval offset to vr 2 0 (0, 3) (0, 3) 3 1 (0x0337, 6) (-1, 6) 4 3 (0x033D, 12) (-3, 12) 5 7 (0x0339, 24) (-7, 24) 6 15 (0x0331, 48) (-15, 48) It seems that 6 bits are needed. Second, setting the 6 LSBs of vmax to 0 gives us 0x300, according to scaling rule, 9 bits will be sent. Third, at the decompressor, the interpretation interval is given by (0 - 127, 0+384) = (0x03ff + 1 - 0x7f, 384) = (0x381, 0x180), v = 0x0333 is NOT in the interval! Notice that since 9 bits are used in encoding, the wraparound boundary is now between 0x03FF and 0 after inserting some unused values. What is the problem here? Thank you. Haipeng _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Nov 21 03:45:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05440 for ; Fri, 21 Nov 2003 03:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6uX-0006tJ-3F for rohc-archive@odin.ietf.org; Fri, 21 Nov 2003 03:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL8j59R026483 for rohc-archive@odin.ietf.org; Fri, 21 Nov 2003 03:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6uW-0006t3-Gi for rohc-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 03:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05400 for ; Fri, 21 Nov 2003 03:44:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6uT-0006Hh-00 for rohc-web-archive@ietf.org; Fri, 21 Nov 2003 03:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN6uT-0006He-00 for rohc-web-archive@ietf.org; Fri, 21 Nov 2003 03:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6uT-0006sk-Ss; Fri, 21 Nov 2003 03:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6ti-0006rf-QR for rohc@optimus.ietf.org; Fri, 21 Nov 2003 03:44:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05375 for ; Fri, 21 Nov 2003 03:44:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6tg-0006HI-00 for rohc@ietf.org; Fri, 21 Nov 2003 03:44:12 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AN6tf-0006HA-00 for rohc@ietf.org; Fri, 21 Nov 2003 03:44:11 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hAL8hqH6011841; Fri, 21 Nov 2003 09:43:52 +0100 (MET) Date: Fri, 21 Nov 2003 09:44:01 +0100 Subject: Re: [rohc] Question about the compress scheme to compress the RTP/UDP/IP/PPP headers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , rohc@ietf.org To: qibaojian From: Carsten Bormann In-Reply-To: <00a901c3afd2$61dfdd80$4104460a@china.huawei.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) 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 > Is the compress scheme to compress the RTP/UDP/IP/PPP headers=20 > unitedly=A0exist? I'm not quite sure about the context for this question, but for PPP=20 over serial, there is very little (one byte) left to compress once you=20= use all of PPP's compression schemes. If you are talking about tunnel aggregates, there is a different, much=20= longer story. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Nov 24 05:14:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02184 for ; Mon, 24 Nov 2003 05:14:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODjJ-0006zl-HW for rohc-archive@odin.ietf.org; Mon, 24 Nov 2003 05:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOAE5n1026890 for rohc-archive@odin.ietf.org; Mon, 24 Nov 2003 05:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODjI-0006zd-KO for rohc-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 05:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02159 for ; Mon, 24 Nov 2003 05:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODjF-0001bU-00 for rohc-web-archive@ietf.org; Mon, 24 Nov 2003 05:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AODjE-0001bQ-00 for rohc-web-archive@ietf.org; Mon, 24 Nov 2003 05:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODjE-0006zN-SG; Mon, 24 Nov 2003 05:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODj8-0006yz-M4 for rohc@optimus.ietf.org; Mon, 24 Nov 2003 05:13:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02148 for ; Mon, 24 Nov 2003 05:13:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODj5-0001bB-00 for rohc@ietf.org; Mon, 24 Nov 2003 05:13:51 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AODj4-0001b5-00 for rohc@ietf.org; Mon, 24 Nov 2003 05:13:50 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAOADiI2014832; Mon, 24 Nov 2003 11:13:50 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 24 Nov 2003 11:13:44 +0100 Message-ID: From: "Jan Christoffersson (LU/EAB)" To: "'West, Mark'" , Robert.Sugar@nokia.com Cc: zhigang.c.liu@nokia.com, "Lars-Erik Jonsson (LU/EAB)" , rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Mon, 24 Nov 2003 11:13:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Mark, I have some concerns about this too... Comments inline. /Jan > Considering (2), something that has not yet been raised is > the use of what > is sometimes referred to as 'continuous mode'. The state model in RFC > 3320 exists for 2 reasons: lack of security between end-points; and > (potential) lack of reliability. The IPsec SA and use of TCP > renders both > of these non-issues. So, why not have a persistent UDVM..? > > This is perfectly reasonable within RFC 3320 -- there is no need for > state-storage, as the UDVM is simply kept running. In order to use the continuous mode and compress messages relative to previous messages, the byte codes need to be tailored for this. This means that we need to know that the receiving endpoint is using continuous mode and this means negotiations. How to do this has not been defined. > Since, in this model, there is no need to align SIP messages > with SigComp > boundaries, the 64kbyte limit need not apply: SigComp ends up simply > providing a compressed TCP stream... > ... so connection close semantics are preserved... Quoting from the RFC 3320: "Decompression failure occurs if the cumulative number of bytes provided to the dispatcher exceeds 65536 bytes." I think that the word cumulative means that you cannot break a large message into little pieces and output them one by one. As soon as the total size is 65 K a decompression failure occurs. I even think that continuous mode could worsen the situation: If several SIP messages are decompressed by the same instance of the UDVM (which could be done in continuous mode)it could happen that decompression failure occurs even if no single message is above the individual limit. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Nov 24 14:43:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23677 for ; Mon, 24 Nov 2003 14:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMbv-0003Iu-7z for rohc-archive@odin.ietf.org; Mon, 24 Nov 2003 14:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOJh3C2012696 for rohc-archive@odin.ietf.org; Mon, 24 Nov 2003 14:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMbv-0003Ih-4V for rohc-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 14:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23673 for ; Mon, 24 Nov 2003 14:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMbs-000397-00 for rohc-web-archive@ietf.org; Mon, 24 Nov 2003 14:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMbr-000394-00 for rohc-web-archive@ietf.org; Mon, 24 Nov 2003 14:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMbs-0003IS-UE; Mon, 24 Nov 2003 14:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMbM-0003Hy-CT for rohc@optimus.ietf.org; Mon, 24 Nov 2003 14:42:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23660 for ; Mon, 24 Nov 2003 14:42:12 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMbJ-00038q-00 for rohc@ietf.org; Mon, 24 Nov 2003 14:42:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOMbI-00038n-00 for rohc@ietf.org; Mon, 24 Nov 2003 14:42:24 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOJgM628430 for ; Mon, 24 Nov 2003 21:42:22 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 21:42:22 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 13:41:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Mon, 24 Nov 2003 13:41:25 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398920@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcOvdqxGFHFu3fjYQ2iziNodlAnKjwDQUDDw To: Cc: X-OriginalArrivalTime: 24 Nov 2003 19:41:25.0356 (UTC) FILETIME=[F23672C0:01C3B2C2] 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 Mark, Thanks for the comments. Please see my reply below. What is your opinion = on this draft as a technical solution for enhancing compression = efficiency?=20 BR, Yousuf > -----Original Message----- > From: ext West, Mark [mailto:mark.a.west@roke.co.uk] > Sent: Thursday, November 20, 2003 10:08 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 >=20 > Hi Yousuf, >=20 > I'm not sure how often you would set up a temporally close sequence of > short-lived connections to different machines on the same subnet > (web-server load balancing, perhaps? but I thought that this=20 > was often > hidden from the user...) Do you have any views on this..? I think it would be quite frequent to consider: - One case is mobile router, e.g. a train connected through a mobile = router to an external network. In this case the IP addresses can be = temporally close. - Another case is Personal Area Network, e.g. a person carrying a group = of bluetooth devices which are connected via a mobile phone to an = external network. In this case also the IP addresses will be temporally = close.=20 - Some networks, e.g. cellular, have IP terminals with same prefix = indicating their gateways for their external networks. >=20 > However, more seriously, I note that the draft has an IPR=20 > statement :-( >=20 > We are trying to make the TCP compression solution as=20 > generally useful as > possible and so the inclusion of an encumbered concept is=20 > something that > I, personally, would object to. Can you clarify this position? > Our IPR folks are sending an IPR disclosure related to this draft with = more information on the following web-page: http://www.ietf.org/ipr.=20 Once that information is available, the WG can look into the information = and can see that it satisfy the needs for generally useful. I would like to say that the proposed IP address compression could be an = additional optional feature on top of basic context replication. As an = optional feature, it should not have concern as an encumber concept. > As a final comment, I'm not sure how helpful the appendix is, since > classless routing has been used since (at least) RFCs 1517/18/19... > (... and site-local addresses in IPv6 are now deprecated ;-) >=20 Thanks. I'll update the appendix. > Cheers, >=20 > Mark. >=20 > -- > Mark A. West, Senior Consultant Engineer > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 >=20 >=20 >=20 > On Wed, 19 Nov 2003 Yousuf.Saifullah@nokia.com wrote: >=20 > > Date: Wed, 19 Nov 2003 13:23:33 -0600 > > From: Yousuf.Saifullah@nokia.com > > To: rohc@ietf.org > > Subject: [rohc] IP Address Compression for Context Replication > > > > Hello, > > The current Context Replication mechanism suggests to send=20 > either whole IP address or no IP address (replication). We=20 > have submitted a draft on the idea of sending compressed IP=20 > address using base IP address. This improves header=20 > compression efficiency when packet flows carry similar (e.g.=20 > same prefix) but not exactly same IP addresses. In=20 > particular, the gain can be significant for IPv6 header=20 > compression due to the large size (16 bytes) of IPv6 addresses. > > > >=20 > http://www.ietf.org/internet-drafts/draft-saifullah-rohc-ip-ad dr-comp-context-replication-00.txt > > This draft has impacts on section 6.5.5.1 of = draft-ietf-rohc-tcp-05.txt, where the format of src/dest IP addresses = are defined for IR-CR. > > Your comments and questions on this draft are more than welcome. > > Regards, > Yousuf > > > _______________________________________________ > 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 Tue Nov 25 04:10:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09433 for ; Tue, 25 Nov 2003 04:10:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZCz-0005bh-2z for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 04:10:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP9A8GH021553 for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 04:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZCx-0005bX-PW for rohc-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 04:10:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09424 for ; Tue, 25 Nov 2003 04:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZCu-0000cN-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 04:10:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOZCt-0000cK-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 04:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZCs-0005ak-Ey; Tue, 25 Nov 2003 04:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZC4-0005ZE-NT for rohc@optimus.ietf.org; Tue, 25 Nov 2003 04:09:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09380 for ; Tue, 25 Nov 2003 04:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZC1-0000bR-00 for rohc@ietf.org; Tue, 25 Nov 2003 04:09:09 -0500 Received: from law15-f61.law15.hotmail.com ([64.4.23.61] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AOZC1-0000av-00 for rohc@ietf.org; Tue, 25 Nov 2003 04:09:09 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Nov 2003 01:08:15 -0800 Received: from 80.74.106.2 by lw15fd.law15.hotmail.msn.com with HTTP; Tue, 25 Nov 2003 09:08:14 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [james_s_ford@hotmail.com] From: "James Ford" To: rohc@ietf.org Date: Tue, 25 Nov 2003 09:08:14 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Nov 2003 09:08:15.0600 (UTC) FILETIME=[A8F77700:01C3B333] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA09381 Subject: [rohc] SIP-SigComp Questions Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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, I'm implementing now the SigComp feature in my SIP application and wonder= ing=20 about some undefined issues in the SigComp/SIP RFCs: (1) A Quotation from the 7th section in RFC 3486 is:=94 If a SIP client s= ends=20 a compressed request and the client transaction times out without having=20 received any response, the client SHOULD retry the same request without=20 using compression.=94 What is the exact meaning of re-sending the same=20 request? Should we use the same transaction for sending the uncompressed=20 message or maybe we should promote the Cseq for handling the situation th= at=20 the server-side actually received the compressed message, decompressed it= =20 and didn=92t manage to reply yet? Moreover, should we change the =91branc= h=92=20 parameter (Via header) in the uncompressed message? (2) Regarding the same quotation from the previous question, how should w= e=20 handle the following scenario: A SIP message should be sent compressed=20 (using SigComp) according to a route list (as a result of DNS request). T= his=20 route list contains four explicit addresses but only the latter is a=20 reachable address. If we=92ll follow the RFC 3486 instructions, then the = SIP=20 message will be sent compressed, a timeout will expire,the same message w= ill=20 be re-sent uncompressed until another timeout will expire and so on. This= =20 process will be repeated for at least three times and might take too long= ,=20 what can we do in order to avoid this slow mechanism? (3) According to RFC 3261:=94 It is RECOMMENDED that connections be kept = open=20 for some implementation-defined duration after the last message was sent = or=20 received over that connection=85 This is to make it likely that transacti= ons=20 are completed over the same connection on which they are initiated (for=20 example, request, response, and in the case of INVITE, ACK for non-2xx=20 responses).=94 The standard recommends on sending all the dialog transact= ions=20 over a single TCP connection. However, RFC 3486 says: =93If a client does= not=20 know whether or not the server supports SigComp, but in case the server=20 supported it, it would like to receive compressed responses, this client=20 SHOULD add the parameter comp=3Dsigcomp to the topmost entry of the Via h= eader=20 field. The request, however, as stated above, will not be compressed.=94= and=20 then says in its 4th section:=94=20 Applications MUST NOT mix SIP messages and SigComp messages on a single T= CP=20 connection. If the TCP connection is used to carry SigComp messages then= =20 all messages that are sent over the connection MUST have a SigComp header= .=94 =20 If we refer to both of the quotations we can conclude that the SigComp=20 standards lead us to use different TCP connections in a single dialog as=20 opposed to the RFC 3261 recommendation, isn=92t it? How can we deal with = this=20 conflict? Best Regards, James. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE*=20 http://join.msn.com/?page=3Dfeatures/junkmail _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 25 05:22:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11150 for ; Tue, 25 Nov 2003 05:22:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaKa-00008H-SX for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 05:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPAM4ax000508 for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 05:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaKa-000087-AK for rohc-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 05:22:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11139 for ; Tue, 25 Nov 2003 05:21:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOaKW-0001On-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 05:22:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOaKW-0001Oj-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 05:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaKW-00007r-IF; Tue, 25 Nov 2003 05:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOH9k-0002VR-EL for rohc@optimus.ietf.org; Mon, 24 Nov 2003 08:53:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08207 for ; Mon, 24 Nov 2003 08:53:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOH9j-0005AM-00 for rohc@ietf.org; Mon, 24 Nov 2003 08:53:35 -0500 Received: from law15-f83.law15.hotmail.com ([64.4.23.83] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AOH9i-00059k-00 for rohc@ietf.org; Mon, 24 Nov 2003 08:53:34 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 Nov 2003 05:53:03 -0800 Received: from 80.74.106.2 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 24 Nov 2003 13:53:03 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [james_s_ford@hotmail.com] From: "James Ford" To: rohc@ietf.org Date: Mon, 24 Nov 2003 13:53:03 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Nov 2003 13:53:03.0866 (UTC) FILETIME=[47F42DA0:01C3B292] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA08208 Subject: [rohc] SIP-SigComp Questions Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: 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, I'm implementing now the SigComp feature in my SIP application and wonder= ing=20 about some undefined issues in the SigComp/SIP RFCs: (1) Can SigComp messages be exchanged intermittently with uncompressed=20 general SIP messages over the same SIP dialog (call)? (2) Is it possible that two different Transactions in the same dialog (ca= ll)=20 will use different Compartment Ids? (3) A Quotation from the 7th section in RFC 3486 is:=94 If a SIP client s= ends=20 a compressed request and the client transaction times out without having=20 received any response, the client SHOULD retry the same request without=20 using compression.=94 What is the exact meaning of re-sending the same=20 request? Should we use the same transaction for sending the uncompressed=20 message or maybe we should promote the Cseq for handling the situation th= at=20 the server-side actually received the compressed message, decompressed it= =20 and didn=92t manage to reply yet? Moreover, should we change the =91branc= h=92=20 parameter (Via header) in the uncompressed message? (4) Regarding the same quotation from the previous question, how should w= e=20 handle the following scenario: A SIP message should be sent compressed=20 (using SigComp) according to a route list (as a result of DNS request). T= his=20 route list contains four explicit addresses but only the latter is a=20 reachable address. If we=92ll follow the RFC 3486 instructions, then the = SIP=20 message will be sent compressed, a timeout will expire,the same message w= ill=20 be re-sent uncompressed until another timeout will expire and so on. This= =20 process will be repeated for at least three times and might take too long= ,=20 what can we do in order to avoid this slow mechanism? (5) According to RFC 3261:=94 It is RECOMMENDED that connections be kept = open=20 for some implementation-defined duration after the last message was sent = or=20 received over that connection=85 This is to make it likely that transacti= ons=20 are completed over the same connection on which they are initiated (for=20 example, request, response, and in the case of INVITE, ACK for non-2xx=20 responses).=94 The standard recommends on sending all the dialog transact= ions=20 over a single TCP connection. However, RFC 3486 says: =93If a client does= not=20 know whether or not the server supports SigComp, but in case the server=20 supported it, it would like to receive compressed responses, this client=20 SHOULD add the parameter comp=3Dsigcomp to the topmost entry of the Via h= eader=20 field. The request, however, as stated above, will not be compressed.=94= and=20 then says in its 4th section:=94=20 Applications MUST NOT mix SIP messages and SigComp messages on a single T= CP=20 connection. If the TCP connection is used to carry SigComp messages then= =20 all messages that are sent over the connection MUST have a SigComp header= .=94 =20 If we refer to both of the quotations we can conclude that the SigComp=20 standards lead us to use different TCP connections in a single dialog as=20 opposed to the RFC 3261 recommendation, isn=92t it? How can we deal with = this=20 conflict? Best Regards, James. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE*=20 http://join.msn.com/?page=3Dfeatures/junkmail _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 25 05:34:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11526 for ; Tue, 25 Nov 2003 05:34:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaWA-0000PB-F1 for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 05:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPAY2IG001553 for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 05:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaWA-0000Oy-85 for rohc-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 05:34:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11483 for ; Tue, 25 Nov 2003 05:33:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOaW6-0001ZG-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 05:33:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOaW6-0001ZD-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 05:33:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaW8-0000Oj-Ns; Tue, 25 Nov 2003 05:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaVg-0000My-5F for rohc@optimus.ietf.org; Tue, 25 Nov 2003 05:33:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11480 for ; Tue, 25 Nov 2003 05:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOaVc-0001Z4-00 for rohc@ietf.org; Tue, 25 Nov 2003 05:33:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOaVb-0001Z1-00 for rohc@ietf.org; Tue, 25 Nov 2003 05:33:28 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPAXRI3000053; Tue, 25 Nov 2003 11:33:28 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 11:33:27 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Yousuf.Saifullah@nokia.com'" , mark.a.west@roke.co.uk Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Tue, 25 Nov 2003 11:33:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , One observation on the non-technical issue... > > However, more seriously, I note that the draft has an IPR > > statement :-( > > > > We are trying to make the TCP compression solution as > > generally useful as possible and so the inclusion of an > > encumbered concept is something that I, personally, would > > object to. Can you clarify this position? > > > Our IPR folks are sending an IPR disclosure related to this > draft with more information on the following web-page: > http://www.ietf.org/ipr. > > Once that information is available, the WG can look into the > information and can see that it satisfy the needs for > generally useful. > > I would like to say that the proposed IP address compression > could be an additional optional feature on top of basic > context replication. As an optional feature, it should not > have concern as an encumber concept. The only way we can have optional features that would not have to be implemented would be by having multiple profiles, as that is our way of providing negotiation of supported functionality. As a general technical comment, I think there are many small optimizations we could do with context replication, but that does not mean it is a good idea to do it. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Nov 25 09:35:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19027 for ; Tue, 25 Nov 2003 09:35:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeHQ-00042j-Kx for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 09:35:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPEZ4Lc015535 for rohc-archive@odin.ietf.org; Tue, 25 Nov 2003 09:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeHQ-00042S-9u for rohc-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09:35:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18997 for ; Tue, 25 Nov 2003 09:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeHO-0005tM-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 09:35:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOeHN-0005tJ-00 for rohc-web-archive@ietf.org; Tue, 25 Nov 2003 09:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeHO-00041q-Dn; Tue, 25 Nov 2003 09:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeGc-00040j-Mw for rohc@optimus.ietf.org; Tue, 25 Nov 2003 09:34:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18962 for ; Tue, 25 Nov 2003 09:34:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeGa-0005sm-00 for rohc@ietf.org; Tue, 25 Nov 2003 09:34:12 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOeGa-0005sh-00 for rohc@ietf.org; Tue, 25 Nov 2003 09:34:12 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPEYASs017976 for ; Tue, 25 Nov 2003 15:34:11 +0100 (MET) Received: by esealnt613.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 15:33:58 +0100 Message-ID: From: "Jan Christoffersson (LU/EAB)" To: "'James Ford'" , rohc@ietf.org Subject: RE: [rohc] SIP-SigComp Questions Date: Tue, 25 Nov 2003 15:33:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi James Your question number 5 is currently being debated on the ROHC list, see http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01809.html and follow-ups. BR Jan > (5) According to RFC 3261:" It is RECOMMENDED that > connections be kept open > for some implementation-defined duration after the last > message was sent or > received over that connection... This is to make it likely that > transactions > are completed over the same connection on which they are > initiated (for > example, request, response, and in the case of INVITE, ACK > for non-2xx > responses)." The standard recommends on sending all the > dialog transactions > over a single TCP connection. However, RFC 3486 says: "If a > client does not > know whether or not the server supports SigComp, but in case > the server > supported it, it would like to receive compressed responses, > this client > SHOULD add the parameter comp=sigcomp to the topmost entry of > the Via header > field. The request, however, as stated above, will not be > compressed." and > then says in its 4th section:" > Applications MUST NOT mix SIP messages and SigComp messages > on a single TCP > connection. If the TCP connection is used to carry SigComp > messages then > all messages that are sent over the connection MUST have a > SigComp header." > If we refer to both of the quotations we can conclude that > the SigComp > standards lead us to use different TCP connections in a > single dialog as > opposed to the RFC 3261 recommendation, isn't it? How can we > deal with this > conflict? > > > Best Regards, > James. > > _________________________________________________________________ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > _______________________________________________ > 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 Nov 27 04:37:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01706 for ; Thu, 27 Nov 2003 04:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIa8-0008W7-5H for rohc-archive@odin.ietf.org; Thu, 27 Nov 2003 04:37:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR9b3sh032726 for rohc-archive@odin.ietf.org; Thu, 27 Nov 2003 04:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIa6-0008Ve-ME for rohc-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 04:37:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01699 for ; Thu, 27 Nov 2003 04:36:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIa3-0005lk-00 for rohc-web-archive@ietf.org; Thu, 27 Nov 2003 04:36:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APIa3-0005lg-00 for rohc-web-archive@ietf.org; Thu, 27 Nov 2003 04:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIa4-0008V7-5R; Thu, 27 Nov 2003 04:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIZD-0008T8-Nt for rohc@optimus.ietf.org; Thu, 27 Nov 2003 04:36:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01653 for ; Thu, 27 Nov 2003 04:35:53 -0500 (EST) From: Robert.Sugar@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIZA-0005kV-00 for rohc@ietf.org; Thu, 27 Nov 2003 04:36:04 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1APIZ9-0005kR-00 for rohc@ietf.org; Thu, 27 Nov 2003 04:36:03 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAR9a3M01106 for ; Thu, 27 Nov 2003 11:36:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Nov 2003 11:36:03 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Nov 2003 11:36:03 +0200 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Nov 2003 11:36:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] SIP-SigComp Questions Date: Thu, 27 Nov 2003 10:35:04 +0100 Message-ID: <21B200DF0688CC45ACF38F49D2279832013396FC@buebe002.europe.nokia.com> Thread-Topic: [rohc] SIP-SigComp Questions Thread-Index: AcOzSkNL4QLGEXWURJq9crWsoZ0edgBeMsDw To: , X-OriginalArrivalTime: 27 Nov 2003 09:36:03.0363 (UTC) FILETIME=[DFDB6730:01C3B4C9] 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 James and others, Let me start with #5, the hot question: It is a very valid point you make here, I was about to raise this as = well. If multiplexing is not allowed we'd have to open a new TCP = connection every time the client is not sure whether or not the server = supports compression, as the first message of the dialog must be = non-SigComp. This is quite a likely case if the server's address was = discovered by external mechanisms (DNS, DHCP, email, etc.). This would = effectively delay the session setup as opposed to the main goal of RFC = 3320. Now to the other questions: #1=20 Yes, as long as the obey the rules of RFC3486. If there is = comp=3Dsigcomp in the Via: header in the initial transaction, but not in = the others, SIP and SigComp messages are interspersed in the same = dialog. #2 This is not clearly defined, and depends on how do you handle = compartments (e.g. is it for one dialog or longer, do you use multiple = compartments, etc.). I would say a SHOULD (be in the same compartment). #3=20 In case of UDP it should be part of the SIP retransmission mechanism = (e.g. first two retransmissions are compressed, third retransmission is = non-SigComp). In case of TCP you may do nothing and wait for timeout, or = resend the same message non-SigComp, risking multiple retransmissions if = there is a general network failure. I favor the second option for the = sake of robustness, although it is not really recommended by SIP. I = would not advise to promote CSeq, since this cannot be done with SIP = responses, only requests. #4 I do not really see the case here, could you elaborate? Do you refer to = forking functionality, or why would one send the request to four = different addresses? BR, Robert > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > James Ford > Sent: November 24,2003 14:53 > To: rohc@ietf.org > Subject: [rohc] SIP-SigComp Questions >=20 >=20 > Hi, >=20 > I'm implementing now the SigComp feature in my SIP=20 > application and wondering=20 > about some undefined issues in the SigComp/SIP RFCs: >=20 > (1) Can SigComp messages be exchanged intermittently with=20 > uncompressed=20 > general SIP messages over the same SIP dialog (call)? >=20 >=20 > 2) Is it possible that two different Transactions in the=20 > same dialog (call)=20 > will use different Compartment Ids? >=20 > (3) A Quotation from the 7th section in RFC 3486 is:" If a=20 > SIP client sends=20 > a compressed request and the client transaction times out=20 > without having=20 > received any response, the client SHOULD retry the same=20 > request without=20 > using compression." What is the exact meaning of re-sending the same=20 > request? Should we use the same transaction for sending the=20 > uncompressed=20 > message or maybe we should promote the Cseq for handling the=20 > situation that=20 > the server-side actually received the compressed message,=20 > decompressed it=20 > and didn't manage to reply yet? Moreover, should we change=20 > the 'branch'=20 > parameter (Via header) in the uncompressed message? >=20 > (4) Regarding the same quotation from the previous question,=20 > how should we=20 > handle the following scenario: A SIP message should be sent=20 > compressed=20 > (using SigComp) according to a route list (as a result of DNS=20 > request). This=20 > route list contains four explicit addresses but only the latter is a=20 > reachable address. If we'll follow the RFC 3486 instructions,=20 > then the SIP=20 > message will be sent compressed, a timeout will expire,the=20 > same message will=20 > be re-sent uncompressed until another timeout will expire and=20 > so on. This=20 > process will be repeated for at least three times and might=20 > take too long,=20 > what can we do in order to avoid this slow mechanism? >=20 > (5) According to RFC 3261:" It is RECOMMENDED that=20 > connections be kept open=20 > for some implementation-defined duration after the last=20 > message was sent or=20 > received over that connection... This is to make it likely that=20 > transactions=20 > are completed over the same connection on which they are=20 > initiated (for=20 > example, request, response, and in the case of INVITE, ACK=20 > for non-2xx=20 > responses)." The standard recommends on sending all the=20 > dialog transactions=20 > over a single TCP connection. However, RFC 3486 says: "If a=20 > client does not=20 > know whether or not the server supports SigComp, but in case=20 > the server=20 > supported it, it would like to receive compressed responses,=20 > this client=20 > SHOULD add the parameter comp=3Dsigcomp to the topmost entry of=20 > the Via header=20 > field. The request, however, as stated above, will not be=20 > compressed." and=20 > then says in its 4th section:"=20 > Applications MUST NOT mix SIP messages and SigComp messages=20 > on a single TCP=20 > connection. If the TCP connection is used to carry SigComp=20 > messages then=20 > all messages that are sent over the connection MUST have a=20 > SigComp header." =20 > If we refer to both of the quotations we can conclude that=20 > the SigComp=20 > standards lead us to use different TCP connections in a=20 > single dialog as=20 > opposed to the RFC 3261 recommendation, isn't it? How can we=20 > deal with this=20 > conflict? >=20 >=20 > Best Regards, > James. >=20 > _________________________________________________________________ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*=20 > http://join.msn.com/?page=3Dfeatures/junkmail >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc