From exim@www1.ietf.org Mon Dec 1 02:25:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11571 for ; Mon, 1 Dec 2003 02:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQiQf-00048e-M5 for rohc-archive@odin.ietf.org; Mon, 01 Dec 2003 02:25:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB17P9Hu015892 for rohc-archive@odin.ietf.org; Mon, 1 Dec 2003 02:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQiQc-00048E-Nb for rohc-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 02: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 CAA11500 for ; Mon, 1 Dec 2003 02:24:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQiQY-0004RJ-00 for rohc-web-archive@ietf.org; Mon, 01 Dec 2003 02:25:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQiQY-0004RG-00 for rohc-web-archive@ietf.org; Mon, 01 Dec 2003 02:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQiQY-00047t-LJ; Mon, 01 Dec 2003 02: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 1AQiPX-0003ty-Nd for rohc@optimus.ietf.org; Mon, 01 Dec 2003 02:24: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 CAA11401 for ; Mon, 1 Dec 2003 02:23:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQiPT-0004Qn-00 for rohc@ietf.org; Mon, 01 Dec 2003 02:23:55 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AQiPT-0004Qc-00 for rohc@ietf.org; Mon, 01 Dec 2003 02:23:55 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id hB16N9jV002696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Dec 2003 07:23:10 +0100 Message-ID: <3FCAEC69.5040300@effnet.com> Date: Mon, 01 Dec 2003 08:23:21 +0100 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lars-Erik Jonsson (LU/EAB)" CC: "'Yousuf.Saifullah@nokia.com'" , mark.a.west@roke.co.uk, rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I don't think it would be a good thing to add this to the Context replication, since it is a very small optimization, cannot be made optional and is IPR-encumbered. BR, Kristofer Sandlund, Effnet AB Lars-Erik Jonsson (LU/EAB) wrote: > 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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Dec 1 06:39:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06735 for ; Mon, 1 Dec 2003 06:39:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmOL-0006yr-RF for rohc-archive@odin.ietf.org; Mon, 01 Dec 2003 06:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Bd1P4026827 for rohc-archive@odin.ietf.org; Mon, 1 Dec 2003 06:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmOL-0006yc-Kz for rohc-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 06:39: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 GAA06728 for ; Mon, 1 Dec 2003 06:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQmOH-00007g-00 for rohc-web-archive@ietf.org; Mon, 01 Dec 2003 06:38:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQmOH-00007d-00 for rohc-web-archive@ietf.org; Mon, 01 Dec 2003 06:38:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmOK-0006yN-1w; Mon, 01 Dec 2003 06:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQmNQ-0006sc-FT for rohc@optimus.ietf.org; Mon, 01 Dec 2003 06:38: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 GAA06720 for ; Mon, 1 Dec 2003 06:37:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQmNA-000077-00 for rohc@ietf.org; Mon, 01 Dec 2003 06:37:48 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AQmN9-000074-00 for rohc@ietf.org; Mon, 01 Dec 2003 06:37:47 -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 hB1BMASs011735; Mon, 1 Dec 2003 12:22:12 +0100 (MET) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7Q72ZS; Mon, 1 Dec 2003 12:22:10 +0100 Received: by lms001.lu.erisoft.se id MAA26420; Mon, 1 Dec 2003 12:22:08 +0100 (MET) Message-ID: <3FCB250B.C2D94885@ericsson.com> Date: Mon, 01 Dec 2003 12:24:59 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cho Chia Yuan CC: rohc@ietf.org, winston@i2r.a-star.edu.sg, sukanta@i2r.a-star.edu.sg References: <97B6AED9BBAE4845B2559DA63E6ECDC2032280A7@MBXSRV23.stu.nus.edu.sg> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id hB1BMASs011735 Content-Transfer-Encoding: quoted-printable Subject: [rohc] Re: Questions on 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 Hi, Thanks for your comments. Hopefully the following will properly address them. > -The above suggests that the feedback channel is compulsory? The presence of an established feedback channel is compulsory for a compressor to have the capability to initiate context replication for a new flow (CID), otherwise no base context (BCID) can be selected as the base for replication. > -Since reverse (positive and negative) feedbacks are all optional,=20 > does it mean that the feedback channel is optional? The usage of feedback from decompressor to compressor for a particular replicated context (CID) is optional. In such case, the compressor is "forced" to operate in a unidirectional manner and the newly replicated context (CID) cannot be used as the base context (BCID) when performing the periodic "refreshes" for that flow (CID). To answer your questions in more details: > 1) Is the reverse feedback channel a compulsory pre-requisite for=20 > context replication or is it optional? The phrasing of the requirement for selecting a base context for replication could be improved. The text in section 3.3.3.1 will be updated to reflect that only a context for which all static information has been acknowledged can be selected as a base context for replication. Thus the requirement does mean that the presence of a feedback channel between decompressor and compressor is compulsory - otherwise a compressor cannot initiate context replication as no context could meet the requirement for a base context. > 2) When the decompressor validation of the context following=20 > decompression of an IR-CR packet fails, is the STATIC-NACK sent back=20 > to the compressor optional or compulsory? Sending feedback (such as STATIC-NACK) is always optional (however it SHOULD be used) for context replication. If the decompressor chooses not to provide feedback for the newly replicated context (thus forcing a unidirectional type of operation), then the compressor will have to periodically transit back to a lower state (IR or IR-CR state) to "refresh" the context. When refreshing the context, the compressor can only use an IR-CR packet if the requirement for the use and selection of a base context is met. In particular, if the original base context previously used does not meet anymore the above requirement, the compressor will have to select another context as a base context. Similarly, as the newly replicated context has not been acknowledged, it cannot either be used as a base for that IR-CR packet. I hope this answers your concerns - otherwise don't hesitate to let me know, also if you have further questions or comments. Best regards, /Ghyslain Cho Chia Yuan wrote: >=20 > Hi Ghyslain, >=20 > I have a few questions regarding > : >=20 > 1) Is the reverse feedback channel a compulsory pre-requisite for=20 > context replication or is it optional? >=20 > 2) When the decompressor validation of the context following=20 > decompression of an IR-CR packet fails, is the STATIC-NACK sent back=20 > to the compressor optional or compulsory? >=20 > The nature of my questions arises from the following: > (3.3.3.) > Context replication is designed to operate over links where a > feedback channel is available. This is necessary to ensure that=20 > the information used to create a new context is synchronized=20 > between the compressor and the decompressor. ... >=20 > -The above suggests that the feedback channel is compulsory? >=20 > (3.4.3.) > Specifically, when the decompressor fails to validate the context > following the decompression of one or more initial IR-CR packets,=20 > it MUST invalidate the context and remain in its initial state. In > addition, the decompressor SHOULD send a STATIC-NACK. >=20 > -Since reverse (positive and negative) feedbacks are all optional,=20 > does it mean that the feedback channel is optional? >=20 >=20 > My opinion is that the reverse feedback channel must be present for=20 > context replication, so that STATIC-NACKS are sent back to the=20 > compressor when context validation fails upon decompression of an IR- > CR packet. IR-CR context validation failures must be communicated=20 > back to the compressor. This is because 'valid' base contexts at the=20 > compressor may be already invalidated at the decompressor. >=20 > The case for this - suppose the reverse feedback channel is not=20 > present (or STATIC-NACKs are not sent back upon context validation=20 > failure at the decompressor), and furthermore the decompressor has=20 > discarded/overwritten all the 'valid' base contexts still kept by the=20 > compressor. Then, the compressor has no way of knowing the truth.=20 > After upwards transition from the CR state in optimistic mode, the=20 > compressor periodically transits downwards to IR state, in which it=20 > finds seemingly 'valid' base contexts, transits to CR state, and=20 > after a period of time optimistically proceeds to the 'Higher Order=20 > State', ... , and all the time nothing has been received successfully=20 > at all. >=20 > Thus, I think STATIC-NACKs for IR-CR packets should not be optional,=20 > because an avenue for fallback to IR packets, in the event of=20 > failure, must be provided. >=20 > Furthermore, if the policy enforced is such that the most recent=20 > valid base context is chosen for replication always, then maybe it=20 > can be assumed that if context validation for an IR-CR packet fails=20 > at the decompressor, there is no need for the compressor to attempt=20 > context replication from another base context? Thus, can the=20 > decompressor simply send back a STATIC-NACK to signal fallback to=20 > conventional context initialization? This may mean that the sending=20 > of STATIC-NACK would be MUST instead of SHOULD in the above section. >=20 > Chia Yuan Cho > National University of Singapore > / Institute for Infocomm Research --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 2 05:57:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11819 for ; Tue, 2 Dec 2003 05:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8DI-0000vc-5W for rohc-archive@odin.ietf.org; Tue, 02 Dec 2003 05:57:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Av4eC003562 for rohc-archive@odin.ietf.org; Tue, 2 Dec 2003 05:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8DH-0000vN-Pi for rohc-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:57: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 FAA11813 for ; Tue, 2 Dec 2003 05:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8DD-0004xL-00 for rohc-web-archive@ietf.org; Tue, 02 Dec 2003 05:57:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR8DD-0004xH-00 for rohc-web-archive@ietf.org; Tue, 02 Dec 2003 05:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8DF-0000v1-K0; Tue, 02 Dec 2003 05:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR2U1-0001Mo-U7 for rohc@optimus.ietf.org; Mon, 01 Dec 2003 23:49: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 XAA20087 for ; Mon, 1 Dec 2003 23:49:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR2Tz-0001AF-00 for rohc@ietf.org; Mon, 01 Dec 2003 23:49:55 -0500 Received: from [203.199.54.34] (helo=mailrelay2.lntinfotech.com) by ietf-mx with esmtp (Exim 4.12) id 1AR2Tz-0001AA-00 for rohc@ietf.org; Mon, 01 Dec 2003 23:49:55 -0500 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by mailrelay2.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2003120210155124:87821 ; Tue, 2 Dec 2003 10:15:51 +0530 To: rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Vikas Warad" Date: Tue, 2 Dec 2003 10:18:27 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 12/02/2003 10:18:30 AM, Itemize by SMTP Server on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 12/02/2003 10:15:51 AM, Serialize by Router on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 12/02/2003 10:15:54 AM, Serialize complete at 12/02/2003 10:15:54 AM Content-type: text/plain; charset=us-ascii Subject: [rohc] 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: , hi all Is the SigComp group still active if yes then few of my questions are as follows 1. Does the UDVM bytecode a part of the compressed data or its a separate code which the decompressor has to load when the length field is zero and when is this done 2. If the later is true then how is this compressed data given to UDVM your's ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Warad Vikas . Dayanand SDC , LNT Infotech ,Brigade road , Bangalore ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 2 12:03:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27450 for ; Tue, 2 Dec 2003 12:03:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDva-0002sB-NN for rohc-archive@odin.ietf.org; Tue, 02 Dec 2003 12:03:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H391Y011020 for rohc-archive@odin.ietf.org; Tue, 2 Dec 2003 12:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDvW-0002r6-C3 for rohc-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 12:03: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 MAA27418 for ; Tue, 2 Dec 2003 12:02:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDvT-0004Pt-00 for rohc-web-archive@ietf.org; Tue, 02 Dec 2003 12:03:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDvT-0004Pq-00 for rohc-web-archive@ietf.org; Tue, 02 Dec 2003 12:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDvU-0002qT-3M; Tue, 02 Dec 2003 12:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDuz-0002ds-B0 for rohc@optimus.ietf.org; Tue, 02 Dec 2003 12:02: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 MAA27376 for ; Tue, 2 Dec 2003 12:02:18 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDux-0004P7-00 for rohc@ietf.org; Tue, 02 Dec 2003 12:02:31 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARDuw-0004P4-00 for rohc@ietf.org; Tue, 02 Dec 2003 12:02:30 -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 hB2H2SN25206 for ; Tue, 2 Dec 2003 19:02:28 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 19:02:28 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 11:02:21 -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: Tue, 2 Dec 2003 11:02:10 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398924@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO33Bwt2cKJtEtXRaOwRZwIaulBPABBHjuw To: , Cc: , X-OriginalArrivalTime: 02 Dec 2003 17:02:21.0241 (UTC) FILETIME=[0CC81290:01C3B8F6] 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 Kristofer and Lars-Erik, Thank you for your comments. I have answered your emails together below. = Regards, Yousuf > -----Original Message----- > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: Monday, December 01, 2003 1:23 AM > To: Lars-Erik Jonsson (LU/EAB) > Cc: Saifullah Yousuf (NRC/Dallas); mark.a.west@roke.co.uk;=20 > rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi all, >=20 > I don't think it would be a good thing to add this to the=20 > Context replication,=20 > since it is a very small optimization, cannot be made optional and is=20 > IPR-encumbered. >=20 Having same prefix in IP addresses, both in IPv4 and IPv6, is quite = common and should be exploited for more compression.=20 Let's take the first objection, "a very small optimization". This is not = a small optimization. An IPv6 address is composed of 16 bytes, and there = is a potential of saving many bytes from both source and destination = addresses. If we assume that the subnet prefix is 64 bits, then it has = potential of saving 8 bytes from an IP address. 8 byte saving is not a = small optimization, if we consider 40 bytes of the total IPv6 header, = then it is 20% saving on the raw IP header. If we consider TCP and IP = header (60 bytes) it still gives 13.33% saving.=20 Also, I have mentioned in my reply to Mark that this case is quite = frequent to consider, I am repeating myself here with one more example: - 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. - Corporate LAN environment has hosts with same prefix. In fact, any = gateway based network would have same prefix for the hosts in its = subnetwork.=20 Let's take the second objection, "cannot be made optional". I think this = objection stem from the fact that the IP address compression solution is = IPR-encumbered, the third objection in your email. Otherwise, if IP = address compression improves compression we don't care it is optional or = mandatory. I have talked to my IPR folks about this objection, and they = agree that everyone should get licenses of the relevent IPR(s) on = reasonable and non-discriminatory (RAND) terms. The official statement = should appear on www.ietf.org/ipr soon, and I am also announcing it on = the mailing list to continue the discussion. I hope this would take away = the IPR concern. I have expanded further on the optional/mandatory = comment in my next comment.=20 =20 > BR, > Kristofer Sandlund, Effnet AB >=20 > Lars-Erik Jonsson (LU/EAB) wrote: > > One observation on the non-technical issue... > >=20 > >=20 > > 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=20 > > functionality.=20 Considering that everyone can implement the IP address compression on = RAND terms, I propose to have this as mandatory part of context = replication. I am borrowing the structure from Page 32 of = http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt to show = the proposed changes in the replication format:=20 replicate_format_0 ::=3D . . . ip_src_addr.discriminator, % 2 bits ip_dst_addr.discriminator, % 2 bits . . . ip_src_addr, % 0 to 32 = bits as indicated by ip_src_addr.discriminator ip_dst_addr, % 0 to 32 = bits as indicated by ip_dst_addr.discriminator . . . The discriminator will indicate no match, full match, prefix match and = suffix match. The discriminator will be similiar to the existing = src/dest port numbers discriminator in the replicate_format_0 structure, = which also indicates more than two sizes of port number values. If we = can allow port numbers to have compressed value, then I think we should = also allow IP addresses to have compressed values. =20 > >=20 > > 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. > >=20 > > /L-E=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 From exim@www1.ietf.org Tue Dec 2 13:00:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00092 for ; Tue, 2 Dec 2003 13:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREok-0007GH-FH for rohc-archive@odin.ietf.org; Tue, 02 Dec 2003 13:00:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2I09wU027907 for rohc-archive@odin.ietf.org; Tue, 2 Dec 2003 13: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 1AREoh-0007Fu-NN for rohc-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 13: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 MAA00052 for ; Tue, 2 Dec 2003 12:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREof-0005Qe-00 for rohc-web-archive@ietf.org; Tue, 02 Dec 2003 13:00:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AREof-0005Qb-00 for rohc-web-archive@ietf.org; Tue, 02 Dec 2003 13:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREod-0007FS-UY; Tue, 02 Dec 2003 13:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREoM-0007EP-FT for rohc@optimus.ietf.org; Tue, 02 Dec 2003 12:59: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 MAA00038 for ; Tue, 2 Dec 2003 12:59:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREoK-0005Q1-00 for rohc@ietf.org; Tue, 02 Dec 2003 12:59:44 -0500 Received: from ims21.stu.nus.edu.sg ([137.132.14.228]) by ietf-mx with esmtp (Exim 4.12) id 1AREoI-0005Pl-00 for rohc@ietf.org; Tue, 02 Dec 2003 12:59:43 -0500 Received: from MBXSRV23.stu.nus.edu.sg ([137.132.14.233]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Wed, 3 Dec 2003 01:59:25 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 3 Dec 2003 01:59:24 +0800 Message-ID: <97B6AED9BBAE4845B2559DA63E6ECDC2032280AB@MBXSRV23.stu.nus.edu.sg> Thread-Topic: Questions on Context Replication Thread-Index: AcO3/5IHalyVW3/DTheCpky0yxEqOwA9BSjc From: "Cho Chia Yuan" To: "Ghyslain Pelletier" Cc: , , X-OriginalArrivalTime: 02 Dec 2003 17:59:25.0882 (UTC) FILETIME=[0606D1A0:01C3B8FE] Content-Transfer-Encoding: base64 Subject: [rohc] RE: Questions on 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: base64 Content-Transfer-Encoding: base64 SGkgR2h5c2xhaW4sDQogDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgdW5kZXJzdGFuZCB0aGF0 IHRoZSByZXZlcnNlIGZlZWRiYWNrIGNoYW5uZWwgbXVzdCBiZSBwcmVzZW50IGZvciBjb250ZXh0 IHJlcGxpY2F0aW9uLCBvciBlbHNlIGNvbnRleHRzIGF0IHRoZSBjb21wcmVzc29yIGNhbm5vdCBi ZSB2ZXJpZmllZCB0byBiZWNvbWUgcG90ZW50aWFsIGJhc2UgY29udGV4dHMuDQogDQpIb3dldmVy LCBjYW4geW91IGVsYWJvcmF0ZSBtb3JlIG9uIHRoZSBvdGhlciBpc3N1ZSAtIHdoeSBpcyBpdCB0 aGF0IFNUQVRJQy1OQUNLIFNIT1VMRCBiZSBzZW50IHdoZW4gdGhlIGRlY29tcHJlc3NvciBmYWls cyB0byB2YWxpZGF0ZSB0aGUgY29udGV4dCBhZnRlciBJUi1DUiBwYWNrZXQgZGVjb21wcmVzc2lv bj8gKE15IHF1ZXN0aW9uIGlzLCB3aHkgU0hPVUxEIGluc3RlYWQgb2YgTVVTVD8pDQogDQpBcyBt ZW50aW9uZWQgaW4gbXkgZWFybGllciBtYWlsLCBpZiBzZW5kaW5nIGJhY2sgU1RBVElDLU5BQ0tz IGFyZSBvcHRpb25hbCBpbnN0ZWFkIG9mIGNvbXB1bHNvcnksIHRoZW4gSVItQ1IgcGFja2V0cyB1 bmlxdWVseSBmYWNlIGEgZGFuZ2VyIG5vdCBlbmNvdW50ZXJlZCBieSBJUiBwYWNrZXRzLiBUaGUg Zm9sbG93aW5nIGlzIG15IGFyZ3VtZW50IGZvciBpdCwgcmVwaHJhc2VkOg0KIA0KTGV0J3Mgc2F5 IGZvciBhIHBhcnRpY3VsYXIgbmV3IGZsb3csIHRoZSBjb21wcmVzc29yIGNob29zZXMgZnJvbSBh IHBvb2wgb2Ygc3VpdGFibGUgYmFzZSBjb250ZXh0cyBmb3IgY29udGV4dCByZXBsaWNhdGlvbiwg YnV0IGFsbCB0aGVpciBlcXVpdmFsZW50cyBhdCB0aGUgZGVjb21wcmVzc29yIGhhdmUgYmVlbiBv dmVyd3JpdHRlbi9kaXNjYXJkZWQsIHdpdGhvdXQgdGhlIGNvbXByZXNzb3IncyBrbm93bGVkZ2Uu IE5hdHVyYWxseSwgYXQgdGhlIGRlY29tcHJlc3NvciwgdmVyaWZpY2F0aW9uIGFmdGVyIElSLUNS IGRlY29tcHJlc3Npb24gZmFpbHMuIFNpbmNlIHNlbmRpbmcgYmFjayBTVEFUSUMtTkFDSyBpcyBv cHRpb25hbCwgaXQgaXMgbm90IHNlbnQuIFRoZSBjb21wcmVzc29yLCBrZXB0IGluIHRoZSBkYXJr LCBjb250aW51ZXMgaW4gb3B0aW1pc3RpYyBtb2RlLCBhbmQgcGVyaW9kaWNhbGx5IHRyYW5zaXRz IGRvd253YXJkcyB0byBJUiBzdGF0ZSwgZGVwZW5kaW5nIG9uIGl0IHRvIHJlZnJlc2ggdGhlIGNv bnRleHQgYXQgdGhlIGRlY29tcHJlc3Nvci4gSG93ZXZlciwgaW4gSVIgc3RhdGUsIHNpbmNlIHNl ZW1pbmdseSAndmFsaWQnIGJhc2UgY29udGV4dHMgYXJlIHByZXNlbnQsIHRoZSBjb21wcmVzc29y IHByb2NlZWRzIHRvIHNlbmQgSVItQ1IgcGFja2V0cyBpbnN0ZWFkLi4uIC4uLiBBdCB0aGUgZGVj b21wcmVzc29yLCB0aGUgZW50aXJlIGZsb3cgaGFzIGJlZW4gZ2liYmVyaXNoLCBhbmQgbm8gZGF0 YSBnZXRzIHNlbnQuDQogDQpNeSBwb2ludCBpcyB0aGF0IHdoZW4gdmVyaWZpY2F0aW9uIGZyb20g SVItQ1IgZmFpbHMsIGEgU1RBVElDLU5BQ0sgTVVTVCAoaW5zdGVhZCBvZiBTSE9VTEQpIGJlIHNl bnQgdG8gbm90aWZ5IHRoZSBjb21wcmVzc29yIHRoYXQgdGhlIGJhc2UgY29udGV4dCBpdCB1c2Vk IGlzIGludmFsaWQsIG90aGVyd2lzZSB0aGUgY29tcHJlc3NvciB3aWxsIGNvbnRpbnVlIHVzaW5n IGl0IHVua25vd2luZ2x5LiBBIHNpZGUgcG9pbnQgaXMgdGhhdCB1c2Ugb2YgSVItQ1IgcGFja2V0 cyB0byByZWZyZXNoIGNvbnRleHRzIGluIG9wdGltaXN0aWMgbW9kZSBjYW5ub3QgYmUgZ3VhcmFu dGVlZCB0byBiZSBhIHN1Y2Nlc3ModW5saWtlIElSIHBhY2tldHMpLCBiZWNhdXNlIHRoZSBlcXVp dmFsZW50IG9mIHRoZSBjb21wcmVzc29yJ3MgYmFzZSBjb250ZXh0IG1heSBubyBsb25nZXIgYmUg a2VwdCBieSB0aGUgZGVjb21wcmVzc29yLiBIb3dldmVyLCBJUi1DUiBwYWNrZXRzIG1heSBzdGls bCBiZSB1c2VkIGZvciBjb250ZXh0IHJlZnJlc2hpbmcgaW4gb3B0aW1pc3RpYyBtb2RlLCBhcyBs b25nIGFzIFNUQVRJQy1OQUNLcyBhcmUgY29tcHVsc29yeSBpbnN0ZWFkIG9mIG9wdGlvbmFsLCB3 aGljaCBpcyB3aGF0IG15IGZpcnN0IHBvaW50IGlzIGFib3V0Lg0KIA0KSG9wZSBteSBxdWVzdGlv biBpcyBjbGVhcmVyIG5vdy4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIHdyb25nIDopDQogDQpD aGlhIFl1YW4gQ2hvDQpOYXRpb25hbCBVbml2ZXJzaXR5IG9mIFNpbmdhcG9yZQ0KL0luc3RpdHV0 ZSBmb3IgSW5mb2NvbW0gUmVzZWFyY2gNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0K CUZyb206IEdoeXNsYWluIFBlbGxldGllciBbbWFpbHRvOkdoeXNsYWluLlBlbGxldGllckBlcmlj c3Nvbi5jb21dIA0KCVNlbnQ6IE1vbiAxMi8xLzIwMDMgNzoyNCBQTSANCglUbzogQ2hvIENoaWEg WXVhbiANCglDYzogcm9oY0BpZXRmLm9yZzsgd2luc3RvbkBpMnIuYS1zdGFyLmVkdS5zZzsgc3Vr YW50YUBpMnIuYS1zdGFyLmVkdS5zZyANCglTdWJqZWN0OiBSZTogUXVlc3Rpb25zIG9uIENvbnRl eHQgUmVwbGljYXRpb24NCgkNCgkNCg0KCUhpLA0KCQ0KCVRoYW5rcyBmb3IgeW91ciBjb21tZW50 cy4gSG9wZWZ1bGx5IHRoZSBmb2xsb3dpbmcgd2lsbCBwcm9wZXJseSBhZGRyZXNzDQoJdGhlbS4N CgkNCgk+IC1UaGUgYWJvdmUgc3VnZ2VzdHMgdGhhdCB0aGUgZmVlZGJhY2sgY2hhbm5lbCBpcyBj b21wdWxzb3J5Pw0KCQ0KCVRoZSBwcmVzZW5jZSBvZiBhbiBlc3RhYmxpc2hlZCBmZWVkYmFjayBj aGFubmVsIGlzIGNvbXB1bHNvcnkgZm9yIGENCgljb21wcmVzc29yIHRvIGhhdmUgdGhlIGNhcGFi aWxpdHkgdG8gaW5pdGlhdGUgY29udGV4dCByZXBsaWNhdGlvbiBmb3IgYQ0KCW5ldyBmbG93IChD SUQpLCBvdGhlcndpc2Ugbm8gYmFzZSBjb250ZXh0IChCQ0lEKSBjYW4gYmUgc2VsZWN0ZWQgYXMg dGhlDQoJYmFzZSBmb3IgcmVwbGljYXRpb24uDQoJDQoJPiAtU2luY2UgcmV2ZXJzZSAocG9zaXRp dmUgYW5kIG5lZ2F0aXZlKSBmZWVkYmFja3MgYXJlIGFsbCBvcHRpb25hbCwNCgk+IGRvZXMgaXQg bWVhbiB0aGF0IHRoZSBmZWVkYmFjayBjaGFubmVsIGlzIG9wdGlvbmFsPw0KCQ0KCVRoZSB1c2Fn ZSBvZiBmZWVkYmFjayBmcm9tIGRlY29tcHJlc3NvciB0byBjb21wcmVzc29yIGZvciBhIHBhcnRp Y3VsYXINCglyZXBsaWNhdGVkIGNvbnRleHQgKENJRCkgaXMgb3B0aW9uYWwuIEluIHN1Y2ggY2Fz ZSwgdGhlIGNvbXByZXNzb3IgaXMNCgkiZm9yY2VkIiB0byBvcGVyYXRlIGluIGEgdW5pZGlyZWN0 aW9uYWwgbWFubmVyIGFuZCB0aGUgbmV3bHkgcmVwbGljYXRlZA0KCWNvbnRleHQgKENJRCkgY2Fu bm90IGJlIHVzZWQgYXMgdGhlIGJhc2UgY29udGV4dCAoQkNJRCkgd2hlbiBwZXJmb3JtaW5nDQoJ dGhlIHBlcmlvZGljICJyZWZyZXNoZXMiIGZvciB0aGF0IGZsb3cgKENJRCkuDQoJDQoJVG8gYW5z d2VyIHlvdXIgcXVlc3Rpb25zIGluIG1vcmUgZGV0YWlsczoNCgkNCgk+IDEpIElzIHRoZSByZXZl cnNlIGZlZWRiYWNrIGNoYW5uZWwgYSBjb21wdWxzb3J5IHByZS1yZXF1aXNpdGUgZm9yDQoJPiBj b250ZXh0IHJlcGxpY2F0aW9uIG9yIGlzIGl0IG9wdGlvbmFsPw0KCQ0KCVRoZSBwaHJhc2luZyBv ZiB0aGUgcmVxdWlyZW1lbnQgZm9yIHNlbGVjdGluZyBhIGJhc2UgY29udGV4dCBmb3INCglyZXBs aWNhdGlvbiBjb3VsZCBiZSBpbXByb3ZlZC4gVGhlIHRleHQgaW4gc2VjdGlvbiAzLjMuMy4xIHdp bGwgYmUNCgl1cGRhdGVkIHRvIHJlZmxlY3QgdGhhdCBvbmx5IGEgY29udGV4dCBmb3Igd2hpY2gg YWxsIHN0YXRpYyBpbmZvcm1hdGlvbg0KCWhhcyBiZWVuIGFja25vd2xlZGdlZCBjYW4gYmUgc2Vs ZWN0ZWQgYXMgYSBiYXNlIGNvbnRleHQgZm9yIHJlcGxpY2F0aW9uLg0KCQ0KCVRodXMgdGhlIHJl cXVpcmVtZW50IGRvZXMgbWVhbiB0aGF0IHRoZSBwcmVzZW5jZSBvZiBhIGZlZWRiYWNrIGNoYW5u ZWwNCgliZXR3ZWVuIGRlY29tcHJlc3NvciBhbmQgY29tcHJlc3NvciBpcyBjb21wdWxzb3J5IC0g b3RoZXJ3aXNlIGENCgljb21wcmVzc29yIGNhbm5vdCBpbml0aWF0ZSBjb250ZXh0IHJlcGxpY2F0 aW9uIGFzIG5vIGNvbnRleHQgY291bGQgbWVldA0KCXRoZSByZXF1aXJlbWVudCBmb3IgYSBiYXNl IGNvbnRleHQuDQoJDQoJPiAyKSBXaGVuIHRoZSBkZWNvbXByZXNzb3IgdmFsaWRhdGlvbiBvZiB0 aGUgY29udGV4dCBmb2xsb3dpbmcNCgk+IGRlY29tcHJlc3Npb24gb2YgYW4gSVItQ1IgcGFja2V0 IGZhaWxzLCBpcyB0aGUgU1RBVElDLU5BQ0sgc2VudCBiYWNrDQoJPiB0byB0aGUgY29tcHJlc3Nv ciBvcHRpb25hbCBvciBjb21wdWxzb3J5Pw0KCQ0KCVNlbmRpbmcgZmVlZGJhY2sgKHN1Y2ggYXMg U1RBVElDLU5BQ0spIGlzIGFsd2F5cyBvcHRpb25hbCAoaG93ZXZlciBpdA0KCVNIT1VMRCBiZSB1 c2VkKSBmb3IgY29udGV4dCByZXBsaWNhdGlvbi4gSWYgdGhlIGRlY29tcHJlc3NvciBjaG9vc2Vz IG5vdA0KCXRvIHByb3ZpZGUgZmVlZGJhY2sgZm9yIHRoZSBuZXdseSByZXBsaWNhdGVkIGNvbnRl eHQgKHRodXMgZm9yY2luZyBhDQoJdW5pZGlyZWN0aW9uYWwgdHlwZSBvZiBvcGVyYXRpb24pLCB0 aGVuIHRoZSBjb21wcmVzc29yIHdpbGwgaGF2ZSB0bw0KCXBlcmlvZGljYWxseSB0cmFuc2l0IGJh Y2sgdG8gYSBsb3dlciBzdGF0ZSAoSVIgb3IgSVItQ1Igc3RhdGUpIHRvDQoJInJlZnJlc2giIHRo ZSBjb250ZXh0Lg0KCQ0KCVdoZW4gcmVmcmVzaGluZyB0aGUgY29udGV4dCwgdGhlIGNvbXByZXNz b3IgY2FuIG9ubHkgdXNlIGFuIElSLUNSIHBhY2tldA0KCWlmIHRoZSByZXF1aXJlbWVudCBmb3Ig dGhlIHVzZSBhbmQgc2VsZWN0aW9uIG9mIGEgYmFzZSBjb250ZXh0IGlzIG1ldC4NCglJbiBwYXJ0 aWN1bGFyLCBpZiB0aGUgb3JpZ2luYWwgYmFzZSBjb250ZXh0IHByZXZpb3VzbHkgdXNlZCBkb2Vz IG5vdA0KCW1lZXQgYW55bW9yZSB0aGUgYWJvdmUgcmVxdWlyZW1lbnQsIHRoZSBjb21wcmVzc29y IHdpbGwgaGF2ZSB0byBzZWxlY3QNCglhbm90aGVyIGNvbnRleHQgYXMgYSBiYXNlIGNvbnRleHQu IFNpbWlsYXJseSwgYXMgdGhlIG5ld2x5IHJlcGxpY2F0ZWQNCgljb250ZXh0IGhhcyBub3QgYmVl biBhY2tub3dsZWRnZWQsIGl0IGNhbm5vdCBlaXRoZXIgYmUgdXNlZCBhcyBhIGJhc2UNCglmb3Ig dGhhdCBJUi1DUiBwYWNrZXQuDQoJDQoJSSBob3BlIHRoaXMgYW5zd2VycyB5b3VyIGNvbmNlcm5z IC0gb3RoZXJ3aXNlIGRvbid0IGhlc2l0YXRlIHRvIGxldCBtZQ0KCWtub3csIGFsc28gaWYgeW91 IGhhdmUgZnVydGhlciBxdWVzdGlvbnMgb3IgY29tbWVudHMuDQoJDQoJQmVzdCByZWdhcmRzLA0K CQ0KCS9HaHlzbGFpbg0KCQ0KCUNobyBDaGlhIFl1YW4gd3JvdGU6DQoJPg0KCT4gSGkgR2h5c2xh aW4sDQoJPg0KCT4gSSBoYXZlIGEgZmV3IHF1ZXN0aW9ucyByZWdhcmRpbmcNCgk+IDxkcmFmdC1p ZXRmLXJvaGMtY29udGV4dC1yZXBsaWNhdGlvbi0wMS50eHQ+Og0KCT4NCgk+IDEpIElzIHRoZSBy ZXZlcnNlIGZlZWRiYWNrIGNoYW5uZWwgYSBjb21wdWxzb3J5IHByZS1yZXF1aXNpdGUgZm9yDQoJ PiBjb250ZXh0IHJlcGxpY2F0aW9uIG9yIGlzIGl0IG9wdGlvbmFsPw0KCT4NCgk+IDIpIFdoZW4g dGhlIGRlY29tcHJlc3NvciB2YWxpZGF0aW9uIG9mIHRoZSBjb250ZXh0IGZvbGxvd2luZw0KCT4g ZGVjb21wcmVzc2lvbiBvZiBhbiBJUi1DUiBwYWNrZXQgZmFpbHMsIGlzIHRoZSBTVEFUSUMtTkFD SyBzZW50IGJhY2sNCgk+IHRvIHRoZSBjb21wcmVzc29yIG9wdGlvbmFsIG9yIGNvbXB1bHNvcnk/ DQoJPg0KCT4gVGhlIG5hdHVyZSBvZiBteSBxdWVzdGlvbnMgYXJpc2VzIGZyb20gdGhlIGZvbGxv d2luZzoNCgk+ICgzLjMuMy4pDQoJPiAgICBDb250ZXh0IHJlcGxpY2F0aW9uIGlzIGRlc2lnbmVk IHRvIG9wZXJhdGUgb3ZlciBsaW5rcyB3aGVyZSBhDQoJPiAgICBmZWVkYmFjayBjaGFubmVsIGlz IGF2YWlsYWJsZS4gVGhpcyBpcyBuZWNlc3NhcnkgdG8gZW5zdXJlIHRoYXQNCgk+ICAgIHRoZSBp bmZvcm1hdGlvbiB1c2VkIHRvIGNyZWF0ZSBhIG5ldyBjb250ZXh0IGlzIHN5bmNocm9uaXplZA0K CT4gICAgYmV0d2VlbiB0aGUgY29tcHJlc3NvciBhbmQgdGhlIGRlY29tcHJlc3Nvci4gLi4uDQoJ Pg0KCT4gLVRoZSBhYm92ZSBzdWdnZXN0cyB0aGF0IHRoZSBmZWVkYmFjayBjaGFubmVsIGlzIGNv bXB1bHNvcnk/DQoJPg0KCT4gKDMuNC4zLikNCgk+ICAgIFNwZWNpZmljYWxseSwgd2hlbiB0aGUg ZGVjb21wcmVzc29yIGZhaWxzIHRvIHZhbGlkYXRlIHRoZSBjb250ZXh0DQoJPiAgICBmb2xsb3dp bmcgdGhlIGRlY29tcHJlc3Npb24gb2Ygb25lIG9yIG1vcmUgaW5pdGlhbCBJUi1DUiBwYWNrZXRz LA0KCT4gICAgaXQgTVVTVCBpbnZhbGlkYXRlIHRoZSBjb250ZXh0IGFuZCByZW1haW4gaW4gaXRz IGluaXRpYWwgc3RhdGUuIEluDQoJPiAgICBhZGRpdGlvbiwgdGhlIGRlY29tcHJlc3NvciBTSE9V TEQgc2VuZCBhIFNUQVRJQy1OQUNLLg0KCT4NCgk+IC1TaW5jZSByZXZlcnNlIChwb3NpdGl2ZSBh bmQgbmVnYXRpdmUpIGZlZWRiYWNrcyBhcmUgYWxsIG9wdGlvbmFsLA0KCT4gZG9lcyBpdCBtZWFu IHRoYXQgdGhlIGZlZWRiYWNrIGNoYW5uZWwgaXMgb3B0aW9uYWw/DQoJPg0KCT4NCgk+IE15IG9w aW5pb24gaXMgdGhhdCB0aGUgcmV2ZXJzZSBmZWVkYmFjayBjaGFubmVsIG11c3QgYmUgcHJlc2Vu dCBmb3INCgk+IGNvbnRleHQgcmVwbGljYXRpb24sIHNvIHRoYXQgU1RBVElDLU5BQ0tTIGFyZSBz ZW50IGJhY2sgdG8gdGhlDQoJPiBjb21wcmVzc29yIHdoZW4gY29udGV4dCB2YWxpZGF0aW9uIGZh aWxzIHVwb24gZGVjb21wcmVzc2lvbiBvZiBhbiBJUi0NCgk+IENSIHBhY2tldC4gSVItQ1IgY29u dGV4dCB2YWxpZGF0aW9uIGZhaWx1cmVzIG11c3QgYmUgY29tbXVuaWNhdGVkDQoJPiBiYWNrIHRv IHRoZSBjb21wcmVzc29yLiBUaGlzIGlzIGJlY2F1c2UgJ3ZhbGlkJyBiYXNlIGNvbnRleHRzIGF0 IHRoZQ0KCT4gY29tcHJlc3NvciBtYXkgYmUgYWxyZWFkeSBpbnZhbGlkYXRlZCBhdCB0aGUgZGVj b21wcmVzc29yLg0KCT4NCgk+IFRoZSBjYXNlIGZvciB0aGlzIC0gc3VwcG9zZSB0aGUgcmV2ZXJz ZSBmZWVkYmFjayBjaGFubmVsIGlzIG5vdA0KCT4gcHJlc2VudCAob3IgU1RBVElDLU5BQ0tzIGFy ZSBub3Qgc2VudCBiYWNrIHVwb24gY29udGV4dCB2YWxpZGF0aW9uDQoJPiBmYWlsdXJlIGF0IHRo ZSBkZWNvbXByZXNzb3IpLCBhbmQgZnVydGhlcm1vcmUgdGhlIGRlY29tcHJlc3NvciBoYXMNCgk+ IGRpc2NhcmRlZC9vdmVyd3JpdHRlbiBhbGwgdGhlICd2YWxpZCcgYmFzZSBjb250ZXh0cyBzdGls bCBrZXB0IGJ5IHRoZQ0KCT4gY29tcHJlc3Nvci4gVGhlbiwgdGhlIGNvbXByZXNzb3IgaGFzIG5v IHdheSBvZiBrbm93aW5nIHRoZSB0cnV0aC4NCgk+IEFmdGVyIHVwd2FyZHMgdHJhbnNpdGlvbiBm cm9tIHRoZSBDUiBzdGF0ZSBpbiBvcHRpbWlzdGljIG1vZGUsIHRoZQ0KCT4gY29tcHJlc3NvciBw ZXJpb2RpY2FsbHkgdHJhbnNpdHMgZG93bndhcmRzIHRvIElSIHN0YXRlLCBpbiB3aGljaCBpdA0K CT4gZmluZHMgc2VlbWluZ2x5ICd2YWxpZCcgYmFzZSBjb250ZXh0cywgdHJhbnNpdHMgdG8gQ1Ig c3RhdGUsIGFuZA0KCT4gYWZ0ZXIgYSBwZXJpb2Qgb2YgdGltZSBvcHRpbWlzdGljYWxseSBwcm9j ZWVkcyB0byB0aGUgJ0hpZ2hlciBPcmRlcg0KCT4gU3RhdGUnLCAuLi4gLCBhbmQgYWxsIHRoZSB0 aW1lIG5vdGhpbmcgaGFzIGJlZW4gcmVjZWl2ZWQgc3VjY2Vzc2Z1bGx5DQoJPiBhdCBhbGwuDQoJ Pg0KCT4gVGh1cywgSSB0aGluayBTVEFUSUMtTkFDS3MgZm9yIElSLUNSIHBhY2tldHMgc2hvdWxk IG5vdCBiZSBvcHRpb25hbCwNCgk+IGJlY2F1c2UgYW4gYXZlbnVlIGZvciBmYWxsYmFjayB0byBJ UiBwYWNrZXRzLCBpbiB0aGUgZXZlbnQgb2YNCgk+IGZhaWx1cmUsIG11c3QgYmUgcHJvdmlkZWQu DQoJPg0KCT4gRnVydGhlcm1vcmUsIGlmIHRoZSBwb2xpY3kgZW5mb3JjZWQgaXMgc3VjaCB0aGF0 IHRoZSBtb3N0IHJlY2VudA0KCT4gdmFsaWQgYmFzZSBjb250ZXh0IGlzIGNob3NlbiBmb3IgcmVw bGljYXRpb24gYWx3YXlzLCB0aGVuIG1heWJlIGl0DQoJPiBjYW4gYmUgYXNzdW1lZCB0aGF0IGlm IGNvbnRleHQgdmFsaWRhdGlvbiBmb3IgYW4gSVItQ1IgcGFja2V0IGZhaWxzDQoJPiBhdCB0aGUg ZGVjb21wcmVzc29yLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgY29tcHJlc3NvciB0byBhdHRl bXB0DQoJPiBjb250ZXh0IHJlcGxpY2F0aW9uIGZyb20gYW5vdGhlciBiYXNlIGNvbnRleHQ/IFRo dXMsIGNhbiB0aGUNCgk+IGRlY29tcHJlc3NvciBzaW1wbHkgc2VuZCBiYWNrIGEgU1RBVElDLU5B Q0sgdG8gc2lnbmFsIGZhbGxiYWNrIHRvDQoJPiBjb252ZW50aW9uYWwgY29udGV4dCBpbml0aWFs aXphdGlvbj8gVGhpcyBtYXkgbWVhbiB0aGF0IHRoZSBzZW5kaW5nDQoJPiBvZiBTVEFUSUMtTkFD SyB3b3VsZCBiZSBNVVNUIGluc3RlYWQgb2YgU0hPVUxEIGluIHRoZSBhYm92ZSBzZWN0aW9uLg0K CT4NCgk+IENoaWEgWXVhbiBDaG8NCgk+IE5hdGlvbmFsIFVuaXZlcnNpdHkgb2YgU2luZ2Fwb3Jl DQoJPiAvIEluc3RpdHV0ZSBmb3IgSW5mb2NvbW0gUmVzZWFyY2gNCgkNCgktLQ0KCUdoeXNsYWlu IFBlbGxldGllciwgRGlwbC4gSW5nLg0KCVdpcmVsZXNzIElQIE9wdGltaXphdGlvbnMNCglBV0FS RSAtIEFkdmFuY2VkIFdpcmVsZXNzIEFsZ29yaXRobSBSZXNlYXJjaA0KCUVyaWNzc29uIFJlc2Vh cmNoLCBDb3Jwb3JhdGUgVW5pdA0KCQ0KCUVyaWNzc29uIEFCLCBMYWJvcmF0b3JpZWdyw6RuZCAx MQ0KCUJveCA5MjAsIFMtOTcxMjggTHVsZcOlLCBTV0VERU4NCglQaG9uZSA6ICs0NiAoMCkgOTIw IDIwIDI0IDMyDQoJTW9iaWxlOiArNDYgKDApIDcwNiAwOSAyNyA3Mw0KCUdoeXNsYWluLlBlbGxl dGllckBlcmljc3Nvbi5jb20NCglodHRwOi8vd3d3LmVyaWNzc29uLmNvbQ0KCQ0KCUkgaGF2ZSBh IG5ldyBtYWlsIGFkZHJlc3M6IEdoeXNsYWluLlBlbGxldGllckBlcmljc3Nvbi5jb20NCglNeSBv bGQgZS1tYWlsIGFkZHJlc3Mgd2lsbCBmdW5jdGlvbiB1bnRpbCAyMDA0LTA2LTAxLg0KCVBsZWFz ZSBjaGFuZ2UgbXkgYWRkcmVzcyBpbiB5b3VyIHBlcnNvbmFsIGFkZHJlc3MgYm9vay4NCgkNCg0K _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 3 09:55:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17314 for ; Wed, 3 Dec 2003 09:55: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 1ARYPC-0000aK-1z for rohc-archive@odin.ietf.org; Wed, 03 Dec 2003 09:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Et6HX002244 for rohc-archive@odin.ietf.org; Wed, 3 Dec 2003 09:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYPB-0000a6-Gi for rohc-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 09:55: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 JAA17283 for ; Wed, 3 Dec 2003 09:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYP9-0002SY-00 for rohc-web-archive@ietf.org; Wed, 03 Dec 2003 09:55:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYP8-0002ST-00 for rohc-web-archive@ietf.org; Wed, 03 Dec 2003 09:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYP7-0000Ze-Gx; Wed, 03 Dec 2003 09: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 1ARYOd-0000WY-0c for rohc@optimus.ietf.org; Wed, 03 Dec 2003 09:54:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17256 for ; Wed, 3 Dec 2003 09:54:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYOa-0002S5-00 for rohc@ietf.org; Wed, 03 Dec 2003 09:54:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARYOa-0002S2-00 for rohc@ietf.org; Wed, 03 Dec 2003 09:54: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 hB3EsRI2002186; Wed, 3 Dec 2003 15:54:27 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Dec 2003 15:54:26 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Yousuf.Saifullah@nokia.com'" Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Wed, 3 Dec 2003 15:53:55 +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: , > Let's take the second objection, "cannot be made optional". I > think this objection stem from the fact that the IP address > compression solution is IPR-encumbered, the third objection > in your email. Actually, my comment was an answer to your proposal to make this an optional feature in context replication, where I noted how such an optional feature would have to be added, i.e. it would require an alternative profile. > I any case, Otherwise, if IP address compression improves > compression we don't care it is optional or mandatory. I have > talked to my IPR folks about this objection, and they agree > that everyone should get licenses of the relevent IPR(s) on > reasonable and non-discriminatory (RAND) terms. The official > statement should appear on www.ietf.org/ipr soon, and I am > also announcing it on the mailing list to continue the > discussion. I hope this would take away the IPR concern. Probably not. RAND-terms is usually not considered sufficient if an "IPR-free" solution is required. > Considering that everyone can implement the IP address > compression on RAND terms, I propose to have this as > mandatory part of context replication. I am borrowing the This is not true, and answers so far have been rather skeptical to the idea, both because of the IPR and for technical reasons. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 3 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 JAA17476 for ; Wed, 3 Dec 2003 09:58: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 1ARYS4-00011X-27 for rohc-archive@odin.ietf.org; Wed, 03 Dec 2003 09:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ew4v0003929 for rohc-archive@odin.ietf.org; Wed, 3 Dec 2003 09:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYS3-00011I-Tx for rohc-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 09:58: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 JAA17461 for ; Wed, 3 Dec 2003 09:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYS1-0002X2-00 for rohc-web-archive@ietf.org; Wed, 03 Dec 2003 09:58:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYS1-0002Wz-00 for rohc-web-archive@ietf.org; Wed, 03 Dec 2003 09:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYS2-000106-Q1; Wed, 03 Dec 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 1ARYRh-0000zN-TX for rohc@optimus.ietf.org; Wed, 03 Dec 2003 09:57: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 JAA17454 for ; Wed, 3 Dec 2003 09:57:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYRf-0002Wq-00 for rohc@ietf.org; Wed, 03 Dec 2003 09:57:39 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARYRe-0002Wn-00 for rohc@ietf.org; Wed, 03 Dec 2003 09:57:39 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB3EvTI2003333; Wed, 3 Dec 2003 15:57:33 +0100 (MET) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW80G0G8; Wed, 3 Dec 2003 15:57:55 +0100 Received: by lms001.lu.erisoft.se id PAA11623; Wed, 3 Dec 2003 15:57:30 +0100 (MET) Message-ID: <3FCDFA79.B3155596@ericsson.com> Date: Wed, 03 Dec 2003 16:00:09 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cho Chia Yuan CC: rohc@ietf.org, winston@i2r.a-star.edu.sg, sukanta@i2r.a-star.edu.sg References: <97B6AED9BBAE4845B2559DA63E6ECDC2032280AB@MBXSRV23.stu.nus.edu.sg> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross-ext.wise.edt.ericsson.se id hB3EvTI2003333 Content-Transfer-Encoding: quoted-printable Subject: [rohc] Re: Questions on 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 Hi, Thanks again for your comments. Hopefully I can clarify this issue, otherwise please correct me if I misunderstand your point. I think that the concerns you have regarding the challenges a compressor is facing when selecting a base context and the differences between IR and IR-CR are already summarized in the draft, in section 3.3.3.1. (see text from "Note however that" of the first paragraph up to the end of the second paragraph of the same section). I believe this is what you are referring to. > Let's say for a particular new flow, the compressor chooses from a=20 > pool of suitable base contexts for context replication, but all their=20 > equivalents at the decompressor have been overwritten/discarded,=20 > without the compressor's knowledge. Naturally, at the decompressor,=20 Secondly, your concerns seem to make some assumptions regarding context management at the compressor. I believe somes assumptions are inaccurate. Recall that CIDs with ROHC are "managed" by the compressor, i.e. the CID is always choosen by the compressor when initiating a new context for a new flow. Overwriting of a CID is thus always known by the compressor - as it is the compressor decision to do so by reusing a CID when initializing a new context - otherwise the CID state is expected to be kept in memory at both ends. This is also true with context replication. However, one could think that a decompressor implementation could be optimized to cleanup the memory space allocated for a CID associated to a connection-oriented flow (e.g. such as TCP) when it detects that the connection has ended (e.g. FIN bit set plus some additional time wait). In such case, there is a possibility that the compressor could select a context as a base context for which the decompressor is not maintaining state anymore - I believe this is your concern, and this is what is explained in section 3.3.3.1. My view is that doing such an optimization at the decompressor is not what is expected of a ROHC decompressor implementation. Therefore, my opinion is that such an "optimization" is an implementation design decision, and hopefully implementers will understand the "risks" being taken so that such an implementation *will* send STATIC-NACK. Hovewer again, removing CID state from memory without this state being explicitly overwritten by the compressor selection of the context identifier is not the expected behaviour, therefore I believe the sending of STATIC-NACK being a SHOULD in the draft is the appropriate wording. > My point is that when verification from IR-CR fails, a STATIC-NACK=20 > MUST (instead of SHOULD) be sent to notify the compressor that the=20 > base context it used is invalid, otherwise the compressor will=20 > continue using it unknowingly. A side point is that use of IR-CR=20 As said, not sending feedback in such case would be a very poor decompressor implementation considering that IR-CR can only be sent if there exist a feedback channel between decompressor and compressor. However, this does not make it a MUST. The occurence of such problem would be due to a decompressor behavior that is not expected by the compressor (otherwise decompression of an IR-CR has little other reasons not to succeed). Such a failure would be the result of an implementation "optimization" that is not performed consequently if no STATIC-NACK is sent upon receiving an IR-CR using a base context that has been removed from the state managed by the decompressor. > A side point is that use of IR-CR=20 > packets to refresh contexts in optimistic mode cannot be guaranteed=20 > to be a success(unlike IR packets), because the equivalent of the=20 > compressor's base context may no longer be kept by the decompressor.=20 But it is guaranteed that failures will be detected, and if the context is no longer kept this is an unexpected behavior for the decompressor.=20 > However, IR-CR packets may still be used for context refreshing in=20 > optimistic mode, as long as STATIC-NACKs are compulsory instead of=20 > optional, which is what my first point is about. Recall also that it is the decompressor that chooses the mode of operation (unidirectional, bidirectional optimistic). The requirements for the compressor to be allowed to use IR-CR implies also that the decompressor as the possibility to send feedback. Finally, I would like to remind the distinction between "SHOULD" and "MUST" from RFC2119: // 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the=20 // definition is an absolute requirement of the specification.=20 // // [snip] // // 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there=20 // may exist valid reasons in particular circumstances to ignore a=20 // particular item, but the full implications must be understood and // carefully weighed before choosing a different course.=20 I thus think "SHOULD" is appropriate. However, I could modify the text to reflect better the possible "implications" of not doing so. /Ghyslain Cho Chia Yuan wrote: >=20 > Hi Ghyslain, >=20 > Thanks for your reply. I understand that the reverse feedback channel > must be present for context replication, or else contexts at the > compressor cannot be verified to become potential base contexts. >=20 > However, can you elaborate more on the other issue - why is it that=20 > STATIC-NACK SHOULD be sent when the decompressor fails to validate=20 > the context after IR-CR packet decompression? (My question is, why=20 > SHOULD instead of MUST?) >=20 > As mentioned in my earlier mail, if sending back STATIC-NACKs are=20 > optional instead of compulsory, then IR-CR packets uniquely face a=20 > danger not encountered by IR packets. The following is my argument=20 > for it, rephrased: > > Let's say for a particular new flow, the compressor chooses from a=20 > pool of suitable base contexts for context replication, but all their=20 > equivalents at the decompressor have been overwritten/discarded,=20 > without the compressor's knowledge. Naturally, at the decompressor,=20 > verification after IR-CR decompression fails. Since sending back=20 > STATIC-NACK is optional, it is not sent. The compressor, kept in the=20 > dark, continues in optimistic mode, and periodically transits=20 > downwards to IR state, depending on it to refresh the context at the=20 > decompressor. However, in IR state, since seemingly 'valid' base=20 > contexts are present, the compressor proceeds to send IR-CR packets=20 > instead... ... At the decompressor, the entire flow has been=20 > gibberish, and no data gets sent. >=20 > My point is that when verification from IR-CR fails, a STATIC-NACK=20 > MUST (instead of SHOULD) be sent to notify the compressor that the=20 > base context it used is invalid, otherwise the compressor will=20 > continue using it unknowingly. A side point is that use of IR-CR=20 > packets to refresh contexts in optimistic mode cannot be guaranteed=20 > to be a success(unlike IR packets), because the equivalent of the=20 > compressor's base context may no longer be kept by the decompressor.=20 > However, IR-CR packets may still be used for context refreshing in=20 > optimistic mode, as long as STATIC-NACKs are compulsory instead of=20 > optional, which is what my first point is about. >=20 > Hope my question is clearer now. Please correct me if I'm wrong :) >=20 > Chia Yuan Cho > National University of Singapore > /Institute for Infocomm Research >=20 > -----Original Message----- > From: Ghyslain Pelletier [mailto:Ghyslain.Pelletier@ericsson.com] > Sent: Mon 12/1/2003 7:24 PM > To: Cho Chia Yuan > Cc: rohc@ietf.org; winston@i2r.a-star.edu.sg; sukanta@i2r.a-star.edu.sg > Subject: Re: Questions on Context Replication >=20 > Hi, >=20 > Thanks for your comments. Hopefully the following will properly address > them. >=20 > > -The above suggests that the feedback channel is compulsory? >=20 > The presence of an established feedback channel is compulsory for a > compressor to have the capability to initiate context replication for a > new flow (CID), otherwise no base context (BCID) can be selected as the > base for replication. >=20 > > -Since reverse (positive and negative) feedbacks are all optional, > > does it mean that the feedback channel is optional? >=20 > The usage of feedback from decompressor to compressor for a particular > replicated context (CID) is optional. In such case, the compressor is > "forced" to operate in a unidirectional manner and the newly replicated > context (CID) cannot be used as the base context (BCID) when performing > the periodic "refreshes" for that flow (CID). >=20 > To answer your questions in more details: >=20 > > 1) Is the reverse feedback channel a compulsory pre-requisite for > > context replication or is it optional? >=20 > The phrasing of the requirement for selecting a base context for > replication could be improved. The text in section 3.3.3.1 will be > updated to reflect that only a context for which all static information > has been acknowledged can be selected as a base context for replication. >=20 > Thus the requirement does mean that the presence of a feedback channel > between decompressor and compressor is compulsory - otherwise a > compressor cannot initiate context replication as no context could meet > the requirement for a base context. >=20 > > 2) When the decompressor validation of the context following > > decompression of an IR-CR packet fails, is the STATIC-NACK sent back > > to the compressor optional or compulsory? >=20 > Sending feedback (such as STATIC-NACK) is always optional (however it > SHOULD be used) for context replication. If the decompressor chooses no= t > to provide feedback for the newly replicated context (thus forcing a > unidirectional type of operation), then the compressor will have to > periodically transit back to a lower state (IR or IR-CR state) to > "refresh" the context. >=20 > When refreshing the context, the compressor can only use an IR-CR packe= t > if the requirement for the use and selection of a base context is met. > In particular, if the original base context previously used does not > meet anymore the above requirement, the compressor will have to select > another context as a base context. Similarly, as the newly replicated > context has not been acknowledged, it cannot either be used as a base > for that IR-CR packet. >=20 > I hope this answers your concerns - otherwise don't hesitate to let me > know, also if you have further questions or comments. >=20 > Best regards, >=20 > /Ghyslain >=20 > Cho Chia Yuan wrote: >> >> Hi Ghyslain, >> >> I have a few questions regarding >> : >> >> 1) Is the reverse feedback channel a compulsory pre-requisite for >> context replication or is it optional? >> >> 2) When the decompressor validation of the context following >> decompression of an IR-CR packet fails, is the STATIC-NACK sent back >> to the compressor optional or compulsory? >> >> The nature of my questions arises from the following: >> (3.3.3.) >> Context replication is designed to operate over links where a >> feedback channel is available. This is necessary to ensure that >> the information used to create a new context is synchronized >> between the compressor and the decompressor. ... >> >> -The above suggests that the feedback channel is compulsory? >> >> (3.4.3.) >> Specifically, when the decompressor fails to validate the context >> following the decompression of one or more initial IR-CR packets, >> it MUST invalidate the context and remain in its initial state. In >> addition, the decompressor SHOULD send a STATIC-NACK. >> >> -Since reverse (positive and negative) feedbacks are all optional, >> does it mean that the feedback channel is optional? >> >> >> My opinion is that the reverse feedback channel must be present for >> context replication, so that STATIC-NACKS are sent back to the >> compressor when context validation fails upon decompression of an IR- >> CR packet. IR-CR context validation failures must be communicated >> back to the compressor. This is because 'valid' base contexts at the >> compressor may be already invalidated at the decompressor. >> >> The case for this - suppose the reverse feedback channel is not >> present (or STATIC-NACKs are not sent back upon context validation >> failure at the decompressor), and furthermore the decompressor has >> discarded/overwritten all the valid base contexts still kept by the >> compressor. Then, the compressor has no way of knowing the truth. >> After upwards transition from the CR state in optimistic mode, the >> compressor periodically transits downwards to IR state, in which it >> finds seemingly 'valid' base contexts, transits to CR state, and >> after a period of time optimistically proceeds to the 'Higher Order >> State', .. , and all the time nothing has been received successfully >> at all. >> >>Thus, I think STATIC-NACKs for IR-CR packets should not be optional, >> because an avenue for fallback to IR packets, in the event of >> failure, must be provided. >> >> Furthermore, if the policy enforced is such that the most recent >> valid base context is chosen for replication always, then maybe it >> can be assumed that if context validation for an IR-CR packet fails >> at the decompressor, there is no need for the compressor to attempt >> context replication from another base context? Thus, can the >> decompressor simply send back a STATIC-NACK to signal fallback to >> conventional context initialization? This may mean that the sending >> of STATIC-NACK would be MUST instead of SHOULD in the above section. >> >> Chia Yuan Cho >> National University of Singapore >> / Institute for Infocomm Research >> -- > Ghyslain Pelletier, Dipl. Ing. > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit > Ericsson AB, Laboratoriegr=C3=A4nd 11 > Box 920, S-97128 Lule=C3=A5, SWEDEN > Phone : +46 (0) 920 20 24 32 > Mobile: +46 (0) 706 09 27 73 > Ghyslain.Pelletier@ericsson.com > http://www.ericsson.com > I have a new mail address: Ghyslain.Pelletier@ericsson.com > My old e-mail address will function until 2004-06-01. > Please change my address in your personal address book. >=20 --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 3 15:30:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04207 for ; Wed, 3 Dec 2003 15:30: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 1ARddS-00029v-7U for rohc-archive@odin.ietf.org; Wed, 03 Dec 2003 15:30:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3KUAmu008293 for rohc-archive@odin.ietf.org; Wed, 3 Dec 2003 15:30:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddS-00029g-3u for rohc-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 15:30: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 PAA04140 for ; Wed, 3 Dec 2003 15:29:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARddQ-0007fj-00 for rohc-web-archive@ietf.org; Wed, 03 Dec 2003 15:30:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARddQ-0007fg-00 for rohc-web-archive@ietf.org; Wed, 03 Dec 2003 15:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddM-00027s-Qc; Wed, 03 Dec 2003 15: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 1ARdcz-00026B-C9 for rohc@optimus.ietf.org; Wed, 03 Dec 2003 15:29:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04066; Wed, 3 Dec 2003 15:29:25 -0500 (EST) Message-Id: <200312032029.PAA04066@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Dec 2003 15:29:24 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-mib-rtp-08.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 : Definitions of Managed Objects for Robus Header Compression Author(s) : J. Quittek Filename : draft-ietf-rohc-mib-rtp-08.txt Pages : 52 Date : 2003-12-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of robust header compression. The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP profile, the ROHC UDP profile, and the ROHC ESP profile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-mib-rtp-08.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-mib-rtp-08.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-mib-rtp-08.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-12-3153012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-mib-rtp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-mib-rtp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-3153012.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 Dec 4 10:53:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02267 for ; Thu, 4 Dec 2003 10:53:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvmp-0007Ah-1Q for rohc-archive@odin.ietf.org; Thu, 04 Dec 2003 10:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Fr3h1027563 for rohc-archive@odin.ietf.org; Thu, 4 Dec 2003 10:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvmo-0007AU-U5 for rohc-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 10:53: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 KAA02206 for ; Thu, 4 Dec 2003 10:52:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvmm-0003k0-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 10:53:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARvmm-0003jv-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 10:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvmn-0007AA-3v; Thu, 04 Dec 2003 10:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvlu-000713-Qb for rohc@optimus.ietf.org; Thu, 04 Dec 2003 10:52: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 KAA02164 for ; Thu, 4 Dec 2003 10:51:48 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvlq-0003iM-00 for rohc@ietf.org; Thu, 04 Dec 2003 10:52:02 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARvlq-0003iJ-00 for rohc@ietf.org; Thu, 04 Dec 2003 10:52:02 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB4Fq0V16883 for ; Thu, 4 Dec 2003 17:52:00 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Dec 2003 17:52:00 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 09:51:44 -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: Thu, 4 Dec 2003 09:51:44 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398929@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO53SzVAq9+pEWERCqN0onJ0rqe0QAnGujA To: , , Cc: X-OriginalArrivalTime: 04 Dec 2003 15:51:44.0938 (UTC) FILETIME=[849308A0:01C3BA7E] 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 Lars-Erik, Thank you for your reply.=20 > This is not true, and answers so far have been rather > skeptical to the idea, both because of the IPR and for > technical reasons. >=20 For IPR reason, I have an update please see the last para of this email. = For technical reasons, allow me to disagree. I still have to see an = argument that this is not a good technical solution. In the emails by = Mark and Kristofer, the concern was raised without any argument that why = it is not a good technical solution. I gave the technical = reasons/advantages, but I didn't see any response back. I am repeating = here again, I would appreciate if someone could comment on the following = and tell me why we are skeptical about savings from IP address = compression = (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt): Having same prefix in IP addresses, both in IPv4 and IPv6, is quite = common and should be exploited for more compression.=20 Let's take the first objection, "a very small optimization". This is not = a small optimization. An IPv6 address is composed of 16 bytes, and there = is a potential of saving many bytes from both source and destination = addresses. If we assume that the subnet prefix is 64 bits, then it has = potential of saving 8 bytes from an IP address. 8 byte saving is not a = small optimization, if we consider 40 bytes of the total IPv6 header, = then it is 20% saving on the raw IP header. If we consider TCP and IP = header (60 bytes) it still gives 13.33% saving.=20 Also, I have mentioned in my reply to Mark that this case is quite = frequent to consider, I am repeating myself here with one more example: - 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. - Corporate LAN environment has hosts with same prefix. In fact, any = gateway based network would have same prefix for the hosts in its = subnetwork.=20 > Probably not. RAND-terms is usually not considered sufficient > if an "IPR-free" solution is required. >=20 I have communicated the WG concern to my IPR folks that RAND-terms is = not sufficient. They should be giving us more information soon. In the = mean time, I would request to the WG to evaluate the IP address = compression proposal technically. If technically it is found worthy of = adoptation, but not found "IPR-free" we can drop the idea. But, if it = also satisfies the IPR-free concern, then why not adopt it. It would = provide more saving. =20 Regards, Yousuf _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 4 13:37:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07639 for ; Thu, 4 Dec 2003 13:37:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyLg-0001A3-Om for rohc-archive@odin.ietf.org; Thu, 04 Dec 2003 13:37:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4IbCNk004449 for rohc-archive@odin.ietf.org; Thu, 4 Dec 2003 13:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyLf-00019Y-Nk for rohc-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 13:37: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 NAA07607 for ; Thu, 4 Dec 2003 13:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyLd-00064R-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 13:37:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARyLc-00064O-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 13:37:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyLV-00015j-20; Thu, 04 Dec 2003 13:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyLJ-00014S-Bw for rohc@optimus.ietf.org; Thu, 04 Dec 2003 13:36:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07597 for ; Thu, 4 Dec 2003 13:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyLE-00064C-00 for rohc@ietf.org; Thu, 04 Dec 2003 13:36:44 -0500 Received: from ims21.stu.nus.edu.sg ([137.132.14.228]) by ietf-mx with esmtp (Exim 4.12) id 1ARyLC-000649-00 for rohc@ietf.org; Thu, 04 Dec 2003 13:36:43 -0500 Received: from MBXSRV23.stu.nus.edu.sg ([137.132.14.233]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Fri, 5 Dec 2003 02:36:30 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 5 Dec 2003 02:36:29 +0800 Message-ID: <97B6AED9BBAE4845B2559DA63E6ECDC2032280B0@MBXSRV23.stu.nus.edu.sg> Thread-Topic: Questions on Context Replication Thread-Index: AcO5rjqVj6wlLwNSQN+0GeN3TNkl9wA5vtOM From: "Cho Chia Yuan" To: "Ghyslain Pelletier" Cc: , , X-OriginalArrivalTime: 04 Dec 2003 18:36:30.0601 (UTC) FILETIME=[88E37F90:01C3BA95] Content-Transfer-Encoding: base64 Subject: [rohc] RE: Questions on 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: base64 Content-Transfer-Encoding: base64 SGkgR2h5c2xhaW4sDQogDQpBIGJpZyB0aGFuayB5b3UgZm9yIHlvdXIgZGV0YWlsZWQgcmVwbHku DQogDQpNeSBzdWdnZXN0aW9uIChvZiBNVVNUIGluc3RlYWQgb2YgU0hPVUxEKSBpcyBvbmUgb2Yg bWFueSBwb3NzaWJsZSBzb2x1dGlvbnMgdG8gdGhlIHByb2JsZW0gb2YgYmFzZSBjb250ZXh0cyBk ZWVtZWQgdmFsaWQgYXQgdGhlIGNvbXByZXNzb3IgYnV0IGFjdHVhbGx5IG5vdCBwcmVzZW50IGF0 IHRoZSBkZWNvbXByZXNzb3IuIFJlZ2FyZGxlc3Mgb2YgdGhlIHNvbHV0aW9uLCBteSBjb25jZXJu IGlzIHRoYXQgc29tZSBub24taW1wbGVtZW50YXRpb24tc3BlY2lmaWMgbWVjaGFuaXNtIHRvIGRl YWwgd2l0aCB0aGUgYWJvdmUgcHJvYmxlbSBzaG91bGQgYmUgaW4gcGxhY2U/DQogDQpNYXliZSBJ IHNob3VsZCBmaXJzdCBlc3RhYmxpc2ggdGhlIGV4aXN0ZW5jZSBvZiB0aGlzIHByb2JsZW0gLSBj YW4gYmFzZSBjb250ZXh0cyBkZWVtZWQgdmFsaWQgYXQgdGhlIGNvbXByZXNzb3IgYmUgaW4gbm9u LWV4aXN0ZW5jZSBhdCB0aGUgZGVjb21wcmVzc29yPw0KIA0KQXMgeW91IGhhdmUgbWVudGlvbmVk IGluIHNlY3Rpb24gMy4zLjMuMSAoc3RhcnRpbmcgZnJvbSAiTm90ZSBob3dldmVyLi4uICIpLCB0 aGlzIHByb2JsZW0gcHJvYmFibHkgZXhpc3RzLCBob3dldmVyIHJlbW90ZSBpdCBpcy4gSSBiZWxp ZXZlIHRoZSBrZXksIHRoZW4sIGxpZXMgaW4gaXRzIHNpZ25pZmljYW5jZSAtIGl0IGlzIGEgbm9u LXByb2JsZW0gaW4gY3VycmVudCBST0hDIG1lY2hhbmlzbXMgd2l0aG91dCBjb250ZXh0IHJlcGxp Y2F0aW9uLCBiZWNhdXNlIGV2ZW4gd2l0aG91dCBmZWVkYmFjaywgcGVyaW9kaWMgZG93bndhcmRz IHRyYW5zaXRpb24gdG8gSVIgc3RhdGUgaXMgZ3VhcmFudGVlZCB0byByZXN5bmNocm9uaXplIHRo ZSBkZWNvbXByZXNzb3IgY29udGV4dC4gSWYgd2UgYWRkIGluIGNvbnRleHQgcmVwbGljYXRpb24s IHRoZW4gd2l0aG91dCBmZWVkYmFjaywgd2UgbWF5IGZpbmQgdGhhdCBwZXJpb2RpYyBkb3dud2Fy ZHMgdHJhbnNpdGlvbiB0byBJUi1DUiBzdGF0ZSBpcyBub3QgZ3VhcmFudGVlZCB0byByZXN5bmNo cm9uaXplIHRoZSBkZWNvbXByZXNzb3IgY29udGV4dCwgYmVjYXVzZSBhbGwgYmFzZSBjb250ZXh0 cyBkZWVtZWQgdmFsaWQgYXQgdGhlIGNvbXByZXNzb3IgbWF5IGJlIGluIG5vbi1leGlzdGVuY2Ug YXQgdGhlIGRlY29tcHJlc3Nvci4NCiANClRoYXQncyB3aHkgSSB0aGluayBjb250ZXh0IHJlcGxp Y2F0aW9uIG5lZWRzIGEgcmV2ZXJzZSBmZWVkYmFjayBjaGFubmVsIChvdGhlciB0aGFuIHVzaW5n IGl0IHRvIHZlcmlmeSBjb250ZXh0cyB0byBiZWNvbWUgYmFzZSBjb250ZXh0cykgZm9yIHNvbWUg a2luZCBvZiBjb21wdWxzb3J5IGZlZWRiYWNrLCBlaXRoZXIgdXBvbiBzdWNjZXNzLCBvciBmYWls dXJlLCBhbmQgZmVlZGJhY2sgaXMgcGVyaGFwcyBtb3JlIGltcG9ydGFudCB3aXRoIGNvbnRleHQg cmVwbGljYXRpb24gdGhhbiB3aXRob3V0Lg0KIA0KUmVnYXJkcywNCkNoaWEgWXVhbiBDaG8NCk5h dGlvbmFsIFVuaXZlcnNpdHkgb2YgU2luZ2Fwb3JlDQovSW5zdGl0dXRlIGZvciBJbmZvY29tbSBS ZXNlYXJjaA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogR2h5c2xhaW4g UGVsbGV0aWVyIFttYWlsdG86R2h5c2xhaW4uUGVsbGV0aWVyQGVyaWNzc29uLmNvbV0gDQoJU2Vu dDogV2VkIDEyLzMvMjAwMyAxMTowMCBQTSANCglUbzogQ2hvIENoaWEgWXVhbiANCglDYzogcm9o Y0BpZXRmLm9yZzsgd2luc3RvbkBpMnIuYS1zdGFyLmVkdS5zZzsgc3VrYW50YUBpMnIuYS1zdGFy LmVkdS5zZyANCglTdWJqZWN0OiBSZTogUXVlc3Rpb25zIG9uIENvbnRleHQgUmVwbGljYXRpb24N CgkNCgkNCg0KCUhpLA0KCQ0KCVRoYW5rcyBhZ2FpbiBmb3IgeW91ciBjb21tZW50cy4gSG9wZWZ1 bGx5IEkgY2FuIGNsYXJpZnkgdGhpcyBpc3N1ZSwNCglvdGhlcndpc2UgcGxlYXNlIGNvcnJlY3Qg bWUgaWYgSSBtaXN1bmRlcnN0YW5kIHlvdXIgcG9pbnQuDQoJDQoJSSB0aGluayB0aGF0IHRoZSBj b25jZXJucyB5b3UgaGF2ZSByZWdhcmRpbmcgdGhlIGNoYWxsZW5nZXMgYSBjb21wcmVzc29yDQoJ aXMgZmFjaW5nIHdoZW4gc2VsZWN0aW5nIGEgYmFzZSBjb250ZXh0IGFuZCB0aGUgZGlmZmVyZW5j ZXMgYmV0d2VlbiBJUg0KCWFuZCBJUi1DUiBhcmUgYWxyZWFkeSBzdW1tYXJpemVkIGluIHRoZSBk cmFmdCwgaW4gc2VjdGlvbiAzLjMuMy4xLiAoc2VlDQoJdGV4dCBmcm9tICJOb3RlIGhvd2V2ZXIg dGhhdCIgb2YgdGhlIGZpcnN0IHBhcmFncmFwaCB1cCB0byB0aGUgZW5kIG9mDQoJdGhlIHNlY29u ZCBwYXJhZ3JhcGggb2YgdGhlIHNhbWUgc2VjdGlvbikuIEkgYmVsaWV2ZSB0aGlzIGlzIHdoYXQg eW91DQoJYXJlIHJlZmVycmluZyB0by4NCgkNCgk+IExldCdzIHNheSBmb3IgYSBwYXJ0aWN1bGFy IG5ldyBmbG93LCB0aGUgY29tcHJlc3NvciBjaG9vc2VzIGZyb20gYQ0KCT4gcG9vbCBvZiBzdWl0 YWJsZSBiYXNlIGNvbnRleHRzIGZvciBjb250ZXh0IHJlcGxpY2F0aW9uLCBidXQgYWxsIHRoZWly DQoJPiBlcXVpdmFsZW50cyBhdCB0aGUgZGVjb21wcmVzc29yIGhhdmUgYmVlbiBvdmVyd3JpdHRl bi9kaXNjYXJkZWQsDQoJPiB3aXRob3V0IHRoZSBjb21wcmVzc29yJ3Mga25vd2xlZGdlLiBOYXR1 cmFsbHksIGF0IHRoZSBkZWNvbXByZXNzb3IsDQoJDQoJU2Vjb25kbHksIHlvdXIgY29uY2VybnMg c2VlbSB0byBtYWtlIHNvbWUgYXNzdW1wdGlvbnMgcmVnYXJkaW5nIGNvbnRleHQNCgltYW5hZ2Vt ZW50IGF0IHRoZSBjb21wcmVzc29yLiBJIGJlbGlldmUgc29tZXMgYXNzdW1wdGlvbnMgYXJlDQoJ aW5hY2N1cmF0ZS4gUmVjYWxsIHRoYXQgQ0lEcyB3aXRoIFJPSEMgYXJlICJtYW5hZ2VkIiBieSB0 aGUgY29tcHJlc3NvciwNCglpLmUuIHRoZSBDSUQgaXMgYWx3YXlzIGNob29zZW4gYnkgdGhlIGNv bXByZXNzb3Igd2hlbiBpbml0aWF0aW5nIGEgbmV3DQoJY29udGV4dCBmb3IgYSBuZXcgZmxvdy4g T3ZlcndyaXRpbmcgb2YgYSBDSUQgaXMgdGh1cyBhbHdheXMga25vd24gYnkgdGhlDQoJY29tcHJl c3NvciAtIGFzIGl0IGlzIHRoZSBjb21wcmVzc29yIGRlY2lzaW9uIHRvIGRvIHNvIGJ5IHJldXNp bmcgYSBDSUQNCgl3aGVuIGluaXRpYWxpemluZyBhIG5ldyBjb250ZXh0IC0gb3RoZXJ3aXNlIHRo ZSBDSUQgc3RhdGUgaXMgZXhwZWN0ZWQgdG8NCgliZSBrZXB0IGluIG1lbW9yeSBhdCBib3RoIGVu ZHMuIFRoaXMgaXMgYWxzbyB0cnVlIHdpdGggY29udGV4dA0KCXJlcGxpY2F0aW9uLg0KCQ0KCUhv d2V2ZXIsIG9uZSBjb3VsZCB0aGluayB0aGF0IGEgZGVjb21wcmVzc29yIGltcGxlbWVudGF0aW9u IGNvdWxkIGJlDQoJb3B0aW1pemVkIHRvIGNsZWFudXAgdGhlIG1lbW9yeSBzcGFjZSBhbGxvY2F0 ZWQgZm9yIGEgQ0lEIGFzc29jaWF0ZWQgdG8NCglhIGNvbm5lY3Rpb24tb3JpZW50ZWQgZmxvdyAo ZS5nLiBzdWNoIGFzIFRDUCkgd2hlbiBpdCBkZXRlY3RzIHRoYXQgdGhlDQoJY29ubmVjdGlvbiBo YXMgZW5kZWQgKGUuZy4gRklOIGJpdCBzZXQgcGx1cyBzb21lIGFkZGl0aW9uYWwgdGltZSB3YWl0 KS4NCglJbiBzdWNoIGNhc2UsIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhhdCB0aGUgY29tcHJl c3NvciBjb3VsZCBzZWxlY3QgYQ0KCWNvbnRleHQgYXMgYSBiYXNlIGNvbnRleHQgZm9yIHdoaWNo IHRoZSBkZWNvbXByZXNzb3IgaXMgbm90IG1haW50YWluaW5nDQoJc3RhdGUgYW55bW9yZSAtIEkg YmVsaWV2ZSB0aGlzIGlzIHlvdXIgY29uY2VybiwgYW5kIHRoaXMgaXMgd2hhdCBpcw0KCWV4cGxh aW5lZCBpbiBzZWN0aW9uIDMuMy4zLjEuDQoJDQoJTXkgdmlldyBpcyB0aGF0IGRvaW5nIHN1Y2gg YW4gb3B0aW1pemF0aW9uIGF0IHRoZSBkZWNvbXByZXNzb3IgaXMgbm90DQoJd2hhdCBpcyBleHBl Y3RlZCBvZiBhIFJPSEMgIGRlY29tcHJlc3NvciBpbXBsZW1lbnRhdGlvbi4gVGhlcmVmb3JlLCBt eQ0KCW9waW5pb24gaXMgdGhhdCBzdWNoIGFuICJvcHRpbWl6YXRpb24iIGlzIGFuIGltcGxlbWVu dGF0aW9uIGRlc2lnbg0KCWRlY2lzaW9uLCBhbmQgaG9wZWZ1bGx5IGltcGxlbWVudGVycyB3aWxs IHVuZGVyc3RhbmQgdGhlICJyaXNrcyIgYmVpbmcNCgl0YWtlbiBzbyB0aGF0IHN1Y2ggYW4gaW1w bGVtZW50YXRpb24gKndpbGwqIHNlbmQgU1RBVElDLU5BQ0suDQoJDQoJSG92ZXdlciBhZ2Fpbiwg cmVtb3ZpbmcgQ0lEIHN0YXRlIGZyb20gbWVtb3J5IHdpdGhvdXQgdGhpcyBzdGF0ZSBiZWluZw0K CWV4cGxpY2l0bHkgb3ZlcndyaXR0ZW4gYnkgdGhlIGNvbXByZXNzb3Igc2VsZWN0aW9uIG9mIHRo ZSBjb250ZXh0DQoJaWRlbnRpZmllciBpcyBub3QgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciwgdGhl cmVmb3JlIEkgYmVsaWV2ZSB0aGUNCglzZW5kaW5nIG9mIFNUQVRJQy1OQUNLIGJlaW5nIGEgU0hP VUxEIGluIHRoZSBkcmFmdCBpcyB0aGUgYXBwcm9wcmlhdGUNCgl3b3JkaW5nLg0KCQ0KCT4gTXkg cG9pbnQgaXMgdGhhdCB3aGVuIHZlcmlmaWNhdGlvbiBmcm9tIElSLUNSIGZhaWxzLCBhIFNUQVRJ Qy1OQUNLDQoJPiBNVVNUIChpbnN0ZWFkIG9mIFNIT1VMRCkgYmUgc2VudCB0byBub3RpZnkgdGhl IGNvbXByZXNzb3IgdGhhdCB0aGUNCgk+IGJhc2UgY29udGV4dCBpdCB1c2VkIGlzIGludmFsaWQs IG90aGVyd2lzZSB0aGUgY29tcHJlc3NvciB3aWxsDQoJPiBjb250aW51ZSB1c2luZyBpdCB1bmtu b3dpbmdseS4gQSBzaWRlIHBvaW50IGlzIHRoYXQgdXNlIG9mIElSLUNSDQoJDQoJQXMgc2FpZCwg bm90IHNlbmRpbmcgZmVlZGJhY2sgaW4gc3VjaCBjYXNlIHdvdWxkIGJlIGEgdmVyeSBwb29yDQoJ ZGVjb21wcmVzc29yIGltcGxlbWVudGF0aW9uIGNvbnNpZGVyaW5nIHRoYXQgSVItQ1IgY2FuIG9u bHkgYmUgc2VudCBpZg0KCXRoZXJlIGV4aXN0IGEgZmVlZGJhY2sgY2hhbm5lbCBiZXR3ZWVuIGRl Y29tcHJlc3NvciBhbmQgY29tcHJlc3Nvci4NCglIb3dldmVyLCB0aGlzIGRvZXMgbm90IG1ha2Ug aXQgYSBNVVNULiBUaGUgb2NjdXJlbmNlIG9mIHN1Y2ggcHJvYmxlbQ0KCXdvdWxkIGJlIGR1ZSB0 byBhIGRlY29tcHJlc3NvciBiZWhhdmlvciB0aGF0IGlzIG5vdCBleHBlY3RlZCBieSB0aGUNCglj b21wcmVzc29yIChvdGhlcndpc2UgZGVjb21wcmVzc2lvbiBvZiBhbiBJUi1DUiBoYXMgbGl0dGxl IG90aGVyIHJlYXNvbnMNCglub3QgdG8gc3VjY2VlZCkuIFN1Y2ggYSBmYWlsdXJlIHdvdWxkIGJl IHRoZSByZXN1bHQgb2YgYW4gaW1wbGVtZW50YXRpb24NCgkib3B0aW1pemF0aW9uIiB0aGF0IGlz IG5vdCBwZXJmb3JtZWQgY29uc2VxdWVudGx5IGlmIG5vIFNUQVRJQy1OQUNLIGlzDQoJc2VudCB1 cG9uIHJlY2VpdmluZyBhbiBJUi1DUiB1c2luZyBhIGJhc2UgY29udGV4dCB0aGF0IGhhcyBiZWVu IHJlbW92ZWQNCglmcm9tIHRoZSBzdGF0ZSBtYW5hZ2VkIGJ5IHRoZSBkZWNvbXByZXNzb3IuDQoJ DQoJPiBBIHNpZGUgcG9pbnQgaXMgdGhhdCB1c2Ugb2YgSVItQ1INCgk+IHBhY2tldHMgdG8gcmVm cmVzaCBjb250ZXh0cyBpbiBvcHRpbWlzdGljIG1vZGUgY2Fubm90IGJlIGd1YXJhbnRlZWQNCgk+ IHRvIGJlIGEgc3VjY2Vzcyh1bmxpa2UgSVIgcGFja2V0cyksIGJlY2F1c2UgdGhlIGVxdWl2YWxl bnQgb2YgdGhlDQoJPiBjb21wcmVzc29yJ3MgYmFzZSBjb250ZXh0IG1heSBubyBsb25nZXIgYmUg a2VwdCBieSB0aGUgZGVjb21wcmVzc29yLg0KCQ0KCUJ1dCBpdCBpcyBndWFyYW50ZWVkIHRoYXQg ZmFpbHVyZXMgd2lsbCBiZSBkZXRlY3RlZCwgYW5kIGlmIHRoZSBjb250ZXh0DQoJaXMgbm8gbG9u Z2VyIGtlcHQgdGhpcyBpcyBhbiB1bmV4cGVjdGVkIGJlaGF2aW9yIGZvciB0aGUgZGVjb21wcmVz c29yLg0KCQ0KCT4gSG93ZXZlciwgSVItQ1IgcGFja2V0cyBtYXkgc3RpbGwgYmUgdXNlZCBmb3Ig Y29udGV4dCByZWZyZXNoaW5nIGluDQoJPiBvcHRpbWlzdGljIG1vZGUsIGFzIGxvbmcgYXMgU1RB VElDLU5BQ0tzIGFyZSBjb21wdWxzb3J5IGluc3RlYWQgb2YNCgk+IG9wdGlvbmFsLCB3aGljaCBp cyB3aGF0IG15IGZpcnN0IHBvaW50IGlzIGFib3V0Lg0KCQ0KCVJlY2FsbCBhbHNvIHRoYXQgaXQg aXMgdGhlIGRlY29tcHJlc3NvciB0aGF0IGNob29zZXMgdGhlIG1vZGUgb2YNCglvcGVyYXRpb24g KHVuaWRpcmVjdGlvbmFsLCBiaWRpcmVjdGlvbmFsIG9wdGltaXN0aWMpLiBUaGUgcmVxdWlyZW1l bnRzDQoJZm9yIHRoZSBjb21wcmVzc29yIHRvIGJlIGFsbG93ZWQgdG8gdXNlIElSLUNSIGltcGxp ZXMgYWxzbyB0aGF0IHRoZQ0KCWRlY29tcHJlc3NvciBhcyB0aGUgcG9zc2liaWxpdHkgdG8gc2Vu ZCBmZWVkYmFjay4NCgkNCglGaW5hbGx5LCBJIHdvdWxkIGxpa2UgdG8gcmVtaW5kIHRoZSBkaXN0 aW5jdGlvbiBiZXR3ZWVuICJTSE9VTEQiIGFuZA0KCSJNVVNUIiBmcm9tIFJGQzIxMTk6DQoJDQoJ Ly8gMS4gTVVTVCBUaGlzIHdvcmQsIG9yIHRoZSB0ZXJtcyAiUkVRVUlSRUQiIG9yICJTSEFMTCIs IG1lYW4gdGhhdCB0aGUNCgkvLyBkZWZpbml0aW9uIGlzIGFuIGFic29sdXRlIHJlcXVpcmVtZW50 IG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0KCS8vDQoJLy8gW3NuaXBdDQoJLy8NCgkvLyAzLiBTSE9V TEQgVGhpcyB3b3JkLCBvciB0aGUgYWRqZWN0aXZlICJSRUNPTU1FTkRFRCIsIG1lYW4gdGhhdCB0 aGVyZQ0KCS8vIG1heSBleGlzdCB2YWxpZCByZWFzb25zIGluIHBhcnRpY3VsYXIgY2lyY3Vtc3Rh bmNlcyB0byBpZ25vcmUgYQ0KCS8vIHBhcnRpY3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxp Y2F0aW9ucyBtdXN0IGJlIHVuZGVyc3Rvb2QgYW5kDQoJLy8gY2FyZWZ1bGx5IHdlaWdoZWQgYmVm b3JlIGNob29zaW5nIGEgZGlmZmVyZW50IGNvdXJzZS4NCgkNCglJIHRodXMgdGhpbmsgIlNIT1VM RCIgaXMgYXBwcm9wcmlhdGUuIEhvd2V2ZXIsIEkgY291bGQgbW9kaWZ5IHRoZSB0ZXh0DQoJdG8g cmVmbGVjdCBiZXR0ZXIgdGhlIHBvc3NpYmxlICJpbXBsaWNhdGlvbnMiIG9mIG5vdCBkb2luZyBz by4NCgkNCgkvR2h5c2xhaW4NCgkNCglDaG8gQ2hpYSBZdWFuIHdyb3RlOg0KCT4NCgk+IEhpIEdo eXNsYWluLA0KCT4NCgk+IFRoYW5rcyBmb3IgeW91ciByZXBseS4gSSB1bmRlcnN0YW5kIHRoYXQg dGhlIHJldmVyc2UgZmVlZGJhY2sgY2hhbm5lbA0KCT4gbXVzdCBiZSBwcmVzZW50IGZvciBjb250 ZXh0IHJlcGxpY2F0aW9uLCBvciBlbHNlIGNvbnRleHRzIGF0IHRoZQ0KCT4gY29tcHJlc3NvciBj YW5ub3QgYmUgdmVyaWZpZWQgdG8gYmVjb21lIHBvdGVudGlhbCBiYXNlIGNvbnRleHRzLg0KCT4N Cgk+IEhvd2V2ZXIsIGNhbiB5b3UgZWxhYm9yYXRlIG1vcmUgb24gdGhlIG90aGVyIGlzc3VlIC0g d2h5IGlzIGl0IHRoYXQNCgk+IFNUQVRJQy1OQUNLIFNIT1VMRCBiZSBzZW50IHdoZW4gdGhlIGRl Y29tcHJlc3NvciBmYWlscyB0byB2YWxpZGF0ZQ0KCT4gdGhlIGNvbnRleHQgYWZ0ZXIgSVItQ1Ig cGFja2V0IGRlY29tcHJlc3Npb24/IChNeSBxdWVzdGlvbiBpcywgd2h5DQoJPiBTSE9VTEQgaW5z dGVhZCBvZiBNVVNUPykNCgk+DQoJPiBBcyBtZW50aW9uZWQgaW4gbXkgZWFybGllciBtYWlsLCBp ZiBzZW5kaW5nIGJhY2sgU1RBVElDLU5BQ0tzIGFyZQ0KCT4gb3B0aW9uYWwgaW5zdGVhZCBvZiBj b21wdWxzb3J5LCB0aGVuIElSLUNSIHBhY2tldHMgdW5pcXVlbHkgZmFjZSBhDQoJPiBkYW5nZXIg bm90IGVuY291bnRlcmVkIGJ5IElSIHBhY2tldHMuIFRoZSBmb2xsb3dpbmcgaXMgbXkgYXJndW1l bnQNCgk+IGZvciBpdCwgcmVwaHJhc2VkOg0KCT4NCgk+IExldCdzIHNheSBmb3IgYSBwYXJ0aWN1 bGFyIG5ldyBmbG93LCB0aGUgY29tcHJlc3NvciBjaG9vc2VzIGZyb20gYQ0KCT4gcG9vbCBvZiBz dWl0YWJsZSBiYXNlIGNvbnRleHRzIGZvciBjb250ZXh0IHJlcGxpY2F0aW9uLCBidXQgYWxsIHRo ZWlyDQoJPiBlcXVpdmFsZW50cyBhdCB0aGUgZGVjb21wcmVzc29yIGhhdmUgYmVlbiBvdmVyd3Jp dHRlbi9kaXNjYXJkZWQsDQoJPiB3aXRob3V0IHRoZSBjb21wcmVzc29yJ3Mga25vd2xlZGdlLiBO YXR1cmFsbHksIGF0IHRoZSBkZWNvbXByZXNzb3IsDQoJPiB2ZXJpZmljYXRpb24gYWZ0ZXIgSVIt Q1IgZGVjb21wcmVzc2lvbiBmYWlscy4gU2luY2Ugc2VuZGluZyBiYWNrDQoJPiBTVEFUSUMtTkFD SyBpcyBvcHRpb25hbCwgaXQgaXMgbm90IHNlbnQuIFRoZSBjb21wcmVzc29yLCBrZXB0IGluIHRo ZQ0KCT4gZGFyaywgY29udGludWVzIGluIG9wdGltaXN0aWMgbW9kZSwgYW5kIHBlcmlvZGljYWxs eSB0cmFuc2l0cw0KCT4gZG93bndhcmRzIHRvIElSIHN0YXRlLCBkZXBlbmRpbmcgb24gaXQgdG8g cmVmcmVzaCB0aGUgY29udGV4dCBhdCB0aGUNCgk+IGRlY29tcHJlc3Nvci4gSG93ZXZlciwgaW4g SVIgc3RhdGUsIHNpbmNlIHNlZW1pbmdseSAndmFsaWQnIGJhc2UNCgk+IGNvbnRleHRzIGFyZSBw cmVzZW50LCB0aGUgY29tcHJlc3NvciBwcm9jZWVkcyB0byBzZW5kIElSLUNSIHBhY2tldHMNCgk+ IGluc3RlYWQuLi4gLi4uIEF0IHRoZSBkZWNvbXByZXNzb3IsIHRoZSBlbnRpcmUgZmxvdyBoYXMg YmVlbg0KCT4gZ2liYmVyaXNoLCBhbmQgbm8gZGF0YSBnZXRzIHNlbnQuDQoJPg0KCT4gTXkgcG9p bnQgaXMgdGhhdCB3aGVuIHZlcmlmaWNhdGlvbiBmcm9tIElSLUNSIGZhaWxzLCBhIFNUQVRJQy1O QUNLDQoJPiBNVVNUIChpbnN0ZWFkIG9mIFNIT1VMRCkgYmUgc2VudCB0byBub3RpZnkgdGhlIGNv bXByZXNzb3IgdGhhdCB0aGUNCgk+IGJhc2UgY29udGV4dCBpdCB1c2VkIGlzIGludmFsaWQsIG90 aGVyd2lzZSB0aGUgY29tcHJlc3NvciB3aWxsDQoJPiBjb250aW51ZSB1c2luZyBpdCB1bmtub3dp bmdseS4gQSBzaWRlIHBvaW50IGlzIHRoYXQgdXNlIG9mIElSLUNSDQoJPiBwYWNrZXRzIHRvIHJl ZnJlc2ggY29udGV4dHMgaW4gb3B0aW1pc3RpYyBtb2RlIGNhbm5vdCBiZSBndWFyYW50ZWVkDQoJ PiB0byBiZSBhIHN1Y2Nlc3ModW5saWtlIElSIHBhY2tldHMpLCBiZWNhdXNlIHRoZSBlcXVpdmFs ZW50IG9mIHRoZQ0KCT4gY29tcHJlc3NvcidzIGJhc2UgY29udGV4dCBtYXkgbm8gbG9uZ2VyIGJl IGtlcHQgYnkgdGhlIGRlY29tcHJlc3Nvci4NCgk+IEhvd2V2ZXIsIElSLUNSIHBhY2tldHMgbWF5 IHN0aWxsIGJlIHVzZWQgZm9yIGNvbnRleHQgcmVmcmVzaGluZyBpbg0KCT4gb3B0aW1pc3RpYyBt b2RlLCBhcyBsb25nIGFzIFNUQVRJQy1OQUNLcyBhcmUgY29tcHVsc29yeSBpbnN0ZWFkIG9mDQoJ PiBvcHRpb25hbCwgd2hpY2ggaXMgd2hhdCBteSBmaXJzdCBwb2ludCBpcyBhYm91dC4NCgk+DQoJ PiBIb3BlIG15IHF1ZXN0aW9uIGlzIGNsZWFyZXIgbm93LiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJ J20gd3JvbmcgOikNCgk+DQoJPiBDaGlhIFl1YW4gQ2hvDQoJPiBOYXRpb25hbCBVbml2ZXJzaXR5 IG9mIFNpbmdhcG9yZQ0KCT4gL0luc3RpdHV0ZSBmb3IgSW5mb2NvbW0gUmVzZWFyY2gNCgk+DQoJ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogR2h5c2xhaW4gUGVsbGV0aWVy IFttYWlsdG86R2h5c2xhaW4uUGVsbGV0aWVyQGVyaWNzc29uLmNvbV0NCgk+IFNlbnQ6IE1vbiAx Mi8xLzIwMDMgNzoyNCBQTQ0KCT4gVG86IENobyBDaGlhIFl1YW4NCgk+IENjOiByb2hjQGlldGYu b3JnOyB3aW5zdG9uQGkyci5hLXN0YXIuZWR1LnNnOyBzdWthbnRhQGkyci5hLXN0YXIuZWR1LnNn DQoJPiBTdWJqZWN0OiBSZTogUXVlc3Rpb25zIG9uIENvbnRleHQgUmVwbGljYXRpb24NCgk+DQoJ PiBIaSwNCgk+DQoJPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIEhvcGVmdWxseSB0aGUgZm9s bG93aW5nIHdpbGwgcHJvcGVybHkgYWRkcmVzcw0KCT4gdGhlbS4NCgk+DQoJPiA+IC1UaGUgYWJv dmUgc3VnZ2VzdHMgdGhhdCB0aGUgZmVlZGJhY2sgY2hhbm5lbCBpcyBjb21wdWxzb3J5Pw0KCT4N Cgk+IFRoZSBwcmVzZW5jZSBvZiBhbiBlc3RhYmxpc2hlZCBmZWVkYmFjayBjaGFubmVsIGlzIGNv bXB1bHNvcnkgZm9yIGENCgk+IGNvbXByZXNzb3IgdG8gaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBp bml0aWF0ZSBjb250ZXh0IHJlcGxpY2F0aW9uIGZvciBhDQoJPiBuZXcgZmxvdyAoQ0lEKSwgb3Ro ZXJ3aXNlIG5vIGJhc2UgY29udGV4dCAoQkNJRCkgY2FuIGJlIHNlbGVjdGVkIGFzIHRoZQ0KCT4g YmFzZSBmb3IgcmVwbGljYXRpb24uDQoJPg0KCT4gPiAtU2luY2UgcmV2ZXJzZSAocG9zaXRpdmUg YW5kIG5lZ2F0aXZlKSBmZWVkYmFja3MgYXJlIGFsbCBvcHRpb25hbCwNCgk+ID4gZG9lcyBpdCBt ZWFuIHRoYXQgdGhlIGZlZWRiYWNrIGNoYW5uZWwgaXMgb3B0aW9uYWw/DQoJPg0KCT4gVGhlIHVz YWdlIG9mIGZlZWRiYWNrIGZyb20gZGVjb21wcmVzc29yIHRvIGNvbXByZXNzb3IgZm9yIGEgcGFy dGljdWxhcg0KCT4gcmVwbGljYXRlZCBjb250ZXh0IChDSUQpIGlzIG9wdGlvbmFsLiBJbiBzdWNo IGNhc2UsIHRoZSBjb21wcmVzc29yIGlzDQoJPiAiZm9yY2VkIiB0byBvcGVyYXRlIGluIGEgdW5p ZGlyZWN0aW9uYWwgbWFubmVyIGFuZCB0aGUgbmV3bHkgcmVwbGljYXRlZA0KCT4gY29udGV4dCAo Q0lEKSBjYW5ub3QgYmUgdXNlZCBhcyB0aGUgYmFzZSBjb250ZXh0IChCQ0lEKSB3aGVuIHBlcmZv cm1pbmcNCgk+IHRoZSBwZXJpb2RpYyAicmVmcmVzaGVzIiBmb3IgdGhhdCBmbG93IChDSUQpLg0K CT4NCgk+IFRvIGFuc3dlciB5b3VyIHF1ZXN0aW9ucyBpbiBtb3JlIGRldGFpbHM6DQoJPg0KCT4g PiAxKSBJcyB0aGUgcmV2ZXJzZSBmZWVkYmFjayBjaGFubmVsIGEgY29tcHVsc29yeSBwcmUtcmVx dWlzaXRlIGZvcg0KCT4gPiBjb250ZXh0IHJlcGxpY2F0aW9uIG9yIGlzIGl0IG9wdGlvbmFsPw0K CT4NCgk+IFRoZSBwaHJhc2luZyBvZiB0aGUgcmVxdWlyZW1lbnQgZm9yIHNlbGVjdGluZyBhIGJh c2UgY29udGV4dCBmb3INCgk+IHJlcGxpY2F0aW9uIGNvdWxkIGJlIGltcHJvdmVkLiBUaGUgdGV4 dCBpbiBzZWN0aW9uIDMuMy4zLjEgd2lsbCBiZQ0KCT4gdXBkYXRlZCB0byByZWZsZWN0IHRoYXQg b25seSBhIGNvbnRleHQgZm9yIHdoaWNoIGFsbCBzdGF0aWMgaW5mb3JtYXRpb24NCgk+IGhhcyBi ZWVuIGFja25vd2xlZGdlZCBjYW4gYmUgc2VsZWN0ZWQgYXMgYSBiYXNlIGNvbnRleHQgZm9yIHJl cGxpY2F0aW9uLg0KCT4NCgk+IFRodXMgdGhlIHJlcXVpcmVtZW50IGRvZXMgbWVhbiB0aGF0IHRo ZSBwcmVzZW5jZSBvZiBhIGZlZWRiYWNrIGNoYW5uZWwNCgk+IGJldHdlZW4gZGVjb21wcmVzc29y IGFuZCBjb21wcmVzc29yIGlzIGNvbXB1bHNvcnkgLSBvdGhlcndpc2UgYQ0KCT4gY29tcHJlc3Nv ciBjYW5ub3QgaW5pdGlhdGUgY29udGV4dCByZXBsaWNhdGlvbiBhcyBubyBjb250ZXh0IGNvdWxk IG1lZXQNCgk+IHRoZSByZXF1aXJlbWVudCBmb3IgYSBiYXNlIGNvbnRleHQuDQoJPg0KCT4gPiAy KSBXaGVuIHRoZSBkZWNvbXByZXNzb3IgdmFsaWRhdGlvbiBvZiB0aGUgY29udGV4dCBmb2xsb3dp bmcNCgk+ID4gZGVjb21wcmVzc2lvbiBvZiBhbiBJUi1DUiBwYWNrZXQgZmFpbHMsIGlzIHRoZSBT VEFUSUMtTkFDSyBzZW50IGJhY2sNCgk+ID4gdG8gdGhlIGNvbXByZXNzb3Igb3B0aW9uYWwgb3Ig Y29tcHVsc29yeT8NCgk+DQoJPiBTZW5kaW5nIGZlZWRiYWNrIChzdWNoIGFzIFNUQVRJQy1OQUNL KSBpcyBhbHdheXMgb3B0aW9uYWwgKGhvd2V2ZXIgaXQNCgk+IFNIT1VMRCBiZSB1c2VkKSBmb3Ig Y29udGV4dCByZXBsaWNhdGlvbi4gSWYgdGhlIGRlY29tcHJlc3NvciBjaG9vc2VzIG5vdA0KCT4g dG8gcHJvdmlkZSBmZWVkYmFjayBmb3IgdGhlIG5ld2x5IHJlcGxpY2F0ZWQgY29udGV4dCAodGh1 cyBmb3JjaW5nIGENCgk+IHVuaWRpcmVjdGlvbmFsIHR5cGUgb2Ygb3BlcmF0aW9uKSwgdGhlbiB0 aGUgY29tcHJlc3NvciB3aWxsIGhhdmUgdG8NCgk+IHBlcmlvZGljYWxseSB0cmFuc2l0IGJhY2sg dG8gYSBsb3dlciBzdGF0ZSAoSVIgb3IgSVItQ1Igc3RhdGUpIHRvDQoJPiAicmVmcmVzaCIgdGhl IGNvbnRleHQuDQoJPg0KCT4gV2hlbiByZWZyZXNoaW5nIHRoZSBjb250ZXh0LCB0aGUgY29tcHJl c3NvciBjYW4gb25seSB1c2UgYW4gSVItQ1IgcGFja2V0DQoJPiBpZiB0aGUgcmVxdWlyZW1lbnQg Zm9yIHRoZSB1c2UgYW5kIHNlbGVjdGlvbiBvZiBhIGJhc2UgY29udGV4dCBpcyBtZXQuDQoJPiBJ biBwYXJ0aWN1bGFyLCBpZiB0aGUgb3JpZ2luYWwgYmFzZSBjb250ZXh0IHByZXZpb3VzbHkgdXNl ZCBkb2VzIG5vdA0KCT4gbWVldCBhbnltb3JlIHRoZSBhYm92ZSByZXF1aXJlbWVudCwgdGhlIGNv bXByZXNzb3Igd2lsbCBoYXZlIHRvIHNlbGVjdA0KCT4gYW5vdGhlciBjb250ZXh0IGFzIGEgYmFz ZSBjb250ZXh0LiBTaW1pbGFybHksIGFzIHRoZSBuZXdseSByZXBsaWNhdGVkDQoJPiBjb250ZXh0 IGhhcyBub3QgYmVlbiBhY2tub3dsZWRnZWQsIGl0IGNhbm5vdCBlaXRoZXIgYmUgdXNlZCBhcyBh IGJhc2UNCgk+IGZvciB0aGF0IElSLUNSIHBhY2tldC4NCgk+DQoJPiBJIGhvcGUgdGhpcyBhbnN3 ZXJzIHlvdXIgY29uY2VybnMgLSBvdGhlcndpc2UgZG9uJ3QgaGVzaXRhdGUgdG8gbGV0IG1lDQoJ PiBrbm93LCBhbHNvIGlmIHlvdSBoYXZlIGZ1cnRoZXIgcXVlc3Rpb25zIG9yIGNvbW1lbnRzLg0K CT4NCgk+IEJlc3QgcmVnYXJkcywNCgk+DQoJPiAvR2h5c2xhaW4NCgk+DQoJPiBDaG8gQ2hpYSBZ dWFuIHdyb3RlOg0KCT4+DQoJPj4gSGkgR2h5c2xhaW4sDQoJPj4NCgk+PiBJIGhhdmUgYSBmZXcg cXVlc3Rpb25zIHJlZ2FyZGluZw0KCT4+IDxkcmFmdC1pZXRmLXJvaGMtY29udGV4dC1yZXBsaWNh dGlvbi0wMS50eHQ+Og0KCT4+DQoJPj4gMSkgSXMgdGhlIHJldmVyc2UgZmVlZGJhY2sgY2hhbm5l bCBhIGNvbXB1bHNvcnkgcHJlLXJlcXVpc2l0ZSBmb3INCgk+PiBjb250ZXh0IHJlcGxpY2F0aW9u IG9yIGlzIGl0IG9wdGlvbmFsPw0KCT4+DQoJPj4gMikgV2hlbiB0aGUgZGVjb21wcmVzc29yIHZh bGlkYXRpb24gb2YgdGhlIGNvbnRleHQgZm9sbG93aW5nDQoJPj4gZGVjb21wcmVzc2lvbiBvZiBh biBJUi1DUiBwYWNrZXQgZmFpbHMsIGlzIHRoZSBTVEFUSUMtTkFDSyBzZW50IGJhY2sNCgk+PiB0 byB0aGUgY29tcHJlc3NvciBvcHRpb25hbCBvciBjb21wdWxzb3J5Pw0KCT4+DQoJPj4gVGhlIG5h dHVyZSBvZiBteSBxdWVzdGlvbnMgYXJpc2VzIGZyb20gdGhlIGZvbGxvd2luZzoNCgk+PiAoMy4z LjMuKQ0KCT4+ICAgIENvbnRleHQgcmVwbGljYXRpb24gaXMgZGVzaWduZWQgdG8gb3BlcmF0ZSBv dmVyIGxpbmtzIHdoZXJlIGENCgk+PiAgICBmZWVkYmFjayBjaGFubmVsIGlzIGF2YWlsYWJsZS4g VGhpcyBpcyBuZWNlc3NhcnkgdG8gZW5zdXJlIHRoYXQNCgk+PiAgICB0aGUgaW5mb3JtYXRpb24g dXNlZCB0byBjcmVhdGUgYSBuZXcgY29udGV4dCBpcyBzeW5jaHJvbml6ZWQNCgk+PiAgICBiZXR3 ZWVuIHRoZSBjb21wcmVzc29yIGFuZCB0aGUgZGVjb21wcmVzc29yLiAuLi4NCgk+Pg0KCT4+IC1U aGUgYWJvdmUgc3VnZ2VzdHMgdGhhdCB0aGUgZmVlZGJhY2sgY2hhbm5lbCBpcyBjb21wdWxzb3J5 Pw0KCT4+DQoJPj4gKDMuNC4zLikNCgk+PiAgIFNwZWNpZmljYWxseSwgd2hlbiB0aGUgZGVjb21w cmVzc29yIGZhaWxzIHRvIHZhbGlkYXRlIHRoZSBjb250ZXh0DQoJPj4gICBmb2xsb3dpbmcgdGhl IGRlY29tcHJlc3Npb24gb2Ygb25lIG9yIG1vcmUgaW5pdGlhbCBJUi1DUiBwYWNrZXRzLA0KCT4+ ICAgaXQgTVVTVCBpbnZhbGlkYXRlIHRoZSBjb250ZXh0IGFuZCByZW1haW4gaW4gaXRzIGluaXRp YWwgc3RhdGUuIEluDQoJPj4gICBhZGRpdGlvbiwgdGhlIGRlY29tcHJlc3NvciBTSE9VTEQgc2Vu ZCBhIFNUQVRJQy1OQUNLLg0KCT4+DQoJPj4gLVNpbmNlIHJldmVyc2UgKHBvc2l0aXZlIGFuZCBu ZWdhdGl2ZSkgZmVlZGJhY2tzIGFyZSBhbGwgb3B0aW9uYWwsDQoJPj4gZG9lcyBpdCBtZWFuIHRo YXQgdGhlIGZlZWRiYWNrIGNoYW5uZWwgaXMgb3B0aW9uYWw/DQoJPj4NCgk+Pg0KCT4+IE15IG9w aW5pb24gaXMgdGhhdCB0aGUgcmV2ZXJzZSBmZWVkYmFjayBjaGFubmVsIG11c3QgYmUgcHJlc2Vu dCBmb3INCgk+PiBjb250ZXh0IHJlcGxpY2F0aW9uLCBzbyB0aGF0IFNUQVRJQy1OQUNLUyBhcmUg c2VudCBiYWNrIHRvIHRoZQ0KCT4+IGNvbXByZXNzb3Igd2hlbiBjb250ZXh0IHZhbGlkYXRpb24g ZmFpbHMgdXBvbiBkZWNvbXByZXNzaW9uIG9mIGFuIElSLQ0KCT4+IENSIHBhY2tldC4gSVItQ1Ig Y29udGV4dCB2YWxpZGF0aW9uIGZhaWx1cmVzIG11c3QgYmUgY29tbXVuaWNhdGVkDQoJPj4gYmFj ayB0byB0aGUgY29tcHJlc3Nvci4gVGhpcyBpcyBiZWNhdXNlICd2YWxpZCcgYmFzZSBjb250ZXh0 cyBhdCB0aGUNCgk+PiBjb21wcmVzc29yIG1heSBiZSBhbHJlYWR5IGludmFsaWRhdGVkIGF0IHRo ZSBkZWNvbXByZXNzb3IuDQoJPj4NCgk+PiBUaGUgY2FzZSBmb3IgdGhpcyAtIHN1cHBvc2UgdGhl IHJldmVyc2UgZmVlZGJhY2sgY2hhbm5lbCBpcyBub3QNCgk+PiBwcmVzZW50IChvciBTVEFUSUMt TkFDS3MgYXJlIG5vdCBzZW50IGJhY2sgdXBvbiBjb250ZXh0IHZhbGlkYXRpb24NCgk+PiBmYWls dXJlIGF0IHRoZSBkZWNvbXByZXNzb3IpLCBhbmQgZnVydGhlcm1vcmUgdGhlIGRlY29tcHJlc3Nv ciBoYXMNCgk+PiBkaXNjYXJkZWQvb3ZlcndyaXR0ZW4gYWxsIHRoZSB2YWxpZCBiYXNlIGNvbnRl eHRzIHN0aWxsIGtlcHQgYnkgdGhlDQoJPj4gY29tcHJlc3Nvci4gVGhlbiwgdGhlIGNvbXByZXNz b3IgaGFzIG5vIHdheSBvZiBrbm93aW5nIHRoZSB0cnV0aC4NCgk+PiBBZnRlciB1cHdhcmRzIHRy YW5zaXRpb24gZnJvbSB0aGUgQ1Igc3RhdGUgaW4gb3B0aW1pc3RpYyBtb2RlLCB0aGUNCgk+PiBj b21wcmVzc29yIHBlcmlvZGljYWxseSB0cmFuc2l0cyBkb3dud2FyZHMgdG8gSVIgc3RhdGUsIGlu IHdoaWNoIGl0DQoJPj4gZmluZHMgc2VlbWluZ2x5ICd2YWxpZCcgYmFzZSBjb250ZXh0cywgdHJh bnNpdHMgdG8gQ1Igc3RhdGUsIGFuZA0KCT4+IGFmdGVyIGEgcGVyaW9kIG9mIHRpbWUgb3B0aW1p c3RpY2FsbHkgcHJvY2VlZHMgdG8gdGhlICdIaWdoZXIgT3JkZXINCgk+PiBTdGF0ZScsIC4uICwg YW5kIGFsbCB0aGUgdGltZSBub3RoaW5nIGhhcyBiZWVuIHJlY2VpdmVkIHN1Y2Nlc3NmdWxseQ0K CT4+IGF0IGFsbC4NCgk+Pg0KCT4+VGh1cywgSSB0aGluayBTVEFUSUMtTkFDS3MgZm9yIElSLUNS IHBhY2tldHMgc2hvdWxkIG5vdCBiZSBvcHRpb25hbCwNCgk+PiBiZWNhdXNlIGFuIGF2ZW51ZSBm b3IgZmFsbGJhY2sgdG8gSVIgcGFja2V0cywgaW4gdGhlIGV2ZW50IG9mDQoJPj4gZmFpbHVyZSwg bXVzdCBiZSBwcm92aWRlZC4NCgk+Pg0KCT4+IEZ1cnRoZXJtb3JlLCBpZiB0aGUgcG9saWN5IGVu Zm9yY2VkIGlzIHN1Y2ggdGhhdCB0aGUgbW9zdCByZWNlbnQNCgk+PiB2YWxpZCBiYXNlIGNvbnRl eHQgaXMgY2hvc2VuIGZvciByZXBsaWNhdGlvbiBhbHdheXMsIHRoZW4gbWF5YmUgaXQNCgk+PiBj YW4gYmUgYXNzdW1lZCB0aGF0IGlmIGNvbnRleHQgdmFsaWRhdGlvbiBmb3IgYW4gSVItQ1IgcGFj a2V0IGZhaWxzDQoJPj4gYXQgdGhlIGRlY29tcHJlc3NvciwgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig dGhlIGNvbXByZXNzb3IgdG8gYXR0ZW1wdA0KCT4+IGNvbnRleHQgcmVwbGljYXRpb24gZnJvbSBh bm90aGVyIGJhc2UgY29udGV4dD8gVGh1cywgY2FuIHRoZQ0KCT4+IGRlY29tcHJlc3NvciBzaW1w bHkgc2VuZCBiYWNrIGEgU1RBVElDLU5BQ0sgdG8gc2lnbmFsIGZhbGxiYWNrIHRvDQoJPj4gY29u dmVudGlvbmFsIGNvbnRleHQgaW5pdGlhbGl6YXRpb24/IFRoaXMgbWF5IG1lYW4gdGhhdCB0aGUg c2VuZGluZw0KCT4+IG9mIFNUQVRJQy1OQUNLIHdvdWxkIGJlIE1VU1QgaW5zdGVhZCBvZiBTSE9V TEQgaW4gdGhlIGFib3ZlIHNlY3Rpb24uDQoJPj4NCgk+PiBDaGlhIFl1YW4gQ2hvDQoJPj4gTmF0 aW9uYWwgVW5pdmVyc2l0eSBvZiBTaW5nYXBvcmUNCgk+PiAvIEluc3RpdHV0ZSBmb3IgSW5mb2Nv bW0gUmVzZWFyY2gNCgk+PiAgICAgICAgIC0tDQoJPiAgR2h5c2xhaW4gUGVsbGV0aWVyLCBEaXBs LiBJbmcuDQoJPiAgV2lyZWxlc3MgSVAgT3B0aW1pemF0aW9ucw0KCT4gIEFXQVJFIC0gQWR2YW5j ZWQgV2lyZWxlc3MgQWxnb3JpdGhtIFJlc2VhcmNoDQoJPiAgRXJpY3Nzb24gUmVzZWFyY2gsIENv cnBvcmF0ZSBVbml0DQoJPiAgRXJpY3Nzb24gQUIsIExhYm9yYXRvcmllZ3LDg8KkbmQgMTENCgk+ ICBCb3ggOTIwLCBTLTk3MTI4IEx1bGXDg8KlLCBTV0VERU4NCgk+ICBQaG9uZSA6ICs0NiAoMCkg OTIwIDIwIDI0IDMyDQoJPiAgTW9iaWxlOiArNDYgKDApIDcwNiAwOSAyNyA3Mw0KCT4gIEdoeXNs YWluLlBlbGxldGllckBlcmljc3Nvbi5jb20NCgk+ICBodHRwOi8vd3d3LmVyaWNzc29uLmNvbQ0K CT4gIEkgaGF2ZSBhIG5ldyBtYWlsIGFkZHJlc3M6IEdoeXNsYWluLlBlbGxldGllckBlcmljc3Nv bi5jb20NCgk+ICBNeSBvbGQgZS1tYWlsIGFkZHJlc3Mgd2lsbCBmdW5jdGlvbiB1bnRpbCAyMDA0 LTA2LTAxLg0KCT4gIFBsZWFzZSBjaGFuZ2UgbXkgYWRkcmVzcyBpbiB5b3VyIHBlcnNvbmFsIGFk ZHJlc3MgYm9vay4NCgk+DQoJDQoJLS0NCglHaHlzbGFpbiBQZWxsZXRpZXIsIERpcGwuIEluZy4N CglXaXJlbGVzcyBJUCBPcHRpbWl6YXRpb25zDQoJQVdBUkUgLSBBZHZhbmNlZCBXaXJlbGVzcyBB bGdvcml0aG0gUmVzZWFyY2gNCglFcmljc3NvbiBSZXNlYXJjaCwgQ29ycG9yYXRlIFVuaXQNCgkN CglFcmljc3NvbiBBQiwgTGFib3JhdG9yaWVncsOkbmQgMTENCglCb3ggOTIwLCBTLTk3MTI4IEx1 bGXDpSwgU1dFREVODQoJUGhvbmUgOiArNDYgKDApIDkyMCAyMCAyNCAzMg0KCU1vYmlsZTogKzQ2 ICgwKSA3MDYgMDkgMjcgNzMNCglHaHlzbGFpbi5QZWxsZXRpZXJAZXJpY3Nzb24uY29tDQoJaHR0 cDovL3d3dy5lcmljc3Nvbi5jb20NCgkNCglJIGhhdmUgYSBuZXcgbWFpbCBhZGRyZXNzOiBHaHlz bGFpbi5QZWxsZXRpZXJAZXJpY3Nzb24uY29tDQoJTXkgb2xkIGUtbWFpbCBhZGRyZXNzIHdpbGwg ZnVuY3Rpb24gdW50aWwgMjAwNC0wNi0wMS4NCglQbGVhc2UgY2hhbmdlIG15IGFkZHJlc3MgaW4g eW91ciBwZXJzb25hbCBhZGRyZXNzIGJvb2suDQoJDQoNCg== _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 4 14:50:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10676 for ; Thu, 4 Dec 2003 14:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzUQ-0005eF-1E for rohc-archive@odin.ietf.org; Thu, 04 Dec 2003 14:50:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4JoIVk021705 for rohc-archive@odin.ietf.org; Thu, 4 Dec 2003 14:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzUP-0005e0-S3 for rohc-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 14:50:17 -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 OAA10668 for ; Thu, 4 Dec 2003 14:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARzUA-0007Ix-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 14:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARzUA-0007Iu-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 14:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzUB-0005cA-Pa; Thu, 04 Dec 2003 14:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzTa-0005aQ-QQ for rohc@optimus.ietf.org; Thu, 04 Dec 2003 14:49: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 OAA10664 for ; Thu, 4 Dec 2003 14:48:58 -0500 (EST) From: ksrini@comcast.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARzTL-0007Ic-00 for rohc@ietf.org; Thu, 04 Dec 2003 14:49:11 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1ARzTL-0007IH-00 for rohc@ietf.org; Thu, 04 Dec 2003 14:49:11 -0500 Received: from 204.127.205.142 ([204.127.205.142]) by comcast.net (sccrmhc11) with SMTP id <200312041948400110052pvfe>; Thu, 4 Dec 2003 19:48:40 +0000 Received: from [129.188.33.222] by 204.127.205.142; Thu, 04 Dec 2003 19:48:39 +0000 To: rohc@ietf.org Subject: UDVM - INPUT beyond message [was: RE: [rohc] input bytes beyond message ] Date: Thu, 04 Dec 2003 19:48:39 +0000 Message-Id: <120420031948.8195.4eea@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 27 2003) X-Authenticated-Sender: a3NyaW5pQGNvbWNhc3QubmV0 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , There was a discussion on the subject on this list. What was decided?? Does anyone know. Here is the pointer to the email-exchanges http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01364.html RFC 3320 does not list any specifics in this regard. It says "If the instruction requests data that lies beyound the end of the SigComp message, no data is returned". Are the residual bytes in the input buffer - discarded? Or are they available for the next valid INPUT instruction? I guess they would be available right? Abigail Surtees Lajos Zaccomer One of you care to comment? Thanks very much -Srini _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 4 15:01:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10913 for ; Thu, 4 Dec 2003 15:01: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 1ARzer-0005qO-5J for rohc-archive@odin.ietf.org; Thu, 04 Dec 2003 15:01:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4K15iZ022457 for rohc-archive@odin.ietf.org; Thu, 4 Dec 2003 15:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzeq-0005q8-Ty for rohc-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 15:01: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 PAA10885 for ; Thu, 4 Dec 2003 15:00:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARzen-0007Ob-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 15:01:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARzen-0007OX-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 15:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzeo-0005pc-HT; Thu, 04 Dec 2003 15:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARze7-0005oU-Nh for rohc@optimus.ietf.org; Thu, 04 Dec 2003 15:00:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10863 for ; Thu, 4 Dec 2003 15:00:02 -0500 (EST) From: ksrini@comcast.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARze4-0007O9-00 for rohc@ietf.org; Thu, 04 Dec 2003 15:00:16 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1ARze4-0007Np-00 for rohc@ietf.org; Thu, 04 Dec 2003 15:00:16 -0500 Received: from 204.127.205.150 ([204.127.205.150]) by comcast.net (sccrmhc11) with SMTP id <200312041959460110057otke>; Thu, 4 Dec 2003 19:59:46 +0000 Received: from [129.188.33.222] by 204.127.205.150; Thu, 04 Dec 2003 19:59:45 +0000 To: rohc@ietf.org Date: Thu, 04 Dec 2003 19:59:45 +0000 Message-Id: <120420031959.28419.6cd2@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 27 2003) X-Authenticated-Sender: a3NyaW5pQGNvbWNhc3QubmV0 Subject: [rohc] SIGCOMP UDVM - byte_copy_left and byte_copy_right 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: , Need some help in understanding the Byte Copying Rules (RFC3320 Section 8.4) 1a) Byte-copying should not result in a write into or beyond memory[byte_copy_right] but can result in writes into memory[byte_copy_left] 1b) Byte-copying should never result in a read from or beyound memory[byte_copy_right] but can result in reads from memory[byte_copy_left] Therefore if the destination is specified as 'byte_copy_right' for a byte-copy instruction - then the writing begins at 'byte_copy_left'. Is this correct interpretation of the rules? 2) Also is byte_copy_right always greater than byte_copy_left? -Srini _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 4 15:09:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11618 for ; Thu, 4 Dec 2003 15:09:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzmZ-0006O4-73 for rohc-archive@odin.ietf.org; Thu, 04 Dec 2003 15:09:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4K93xq024546 for rohc-archive@odin.ietf.org; Thu, 4 Dec 2003 15:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzmZ-0006Np-2v for rohc-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 15:09: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 PAA11563 for ; Thu, 4 Dec 2003 15:08:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARzmV-0007VT-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 15:08:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARzmV-0007VQ-00 for rohc-web-archive@ietf.org; Thu, 04 Dec 2003 15:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzmX-0006NG-DA; Thu, 04 Dec 2003 15: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 1ARzlZ-0006GL-AR for rohc@optimus.ietf.org; Thu, 04 Dec 2003 15:08: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 PAA11427 for ; Thu, 4 Dec 2003 15:07:44 -0500 (EST) From: ksrini@comcast.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARzlV-0007UU-00 for rohc@ietf.org; Thu, 04 Dec 2003 15:07:57 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1ARzlU-0007U1-00 for rohc@ietf.org; Thu, 04 Dec 2003 15:07:57 -0500 Received: from 204.127.205.145 ([204.127.205.145]) by comcast.net (sccrmhc13) with SMTP id <200312042007250160088cume>; Thu, 4 Dec 2003 20:07:25 +0000 Received: from [129.188.33.222] by 204.127.205.145; Thu, 04 Dec 2003 20:07:23 +0000 To: rohc@ietf.org Subject: RE: [rohc] questions Date: Thu, 04 Dec 2003 20:07:23 +0000 Message-Id: <120420032007.15169.199a@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 27 2003) X-Authenticated-Sender: a3NyaW5pQGNvbWNhc3QubmV0 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: , Vikas, See Figure 3. Section 7 in RFC 3320 Shows the sigcomp message format. One of the forms of the SIGCOMP message is sigcomp header + decompression bytecode + compressed application msg SO answer to your question 1 is yes .. the bytecode comes as part of the sigcomp message (when len=0). -Srini To: rohc@ietf.org Subject: [rohc] questions From: "Vikas Warad" Date: Tue, 2 Dec 2003 10:18:27 +0530 -------------------------------------------------------------------------------- hi all Is the SigComp group still active if yes then few of my questions are as follows 1. Does the UDVM bytecode a part of the compressed data or its a separate code which the decompressor has to load when the length field is zero and when is this done 2. If the later is true then how is this compressed data given to UDVM _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 5 02:59:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24962 for ; Fri, 5 Dec 2003 02: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 1ASArh-0000Kd-MP for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 02:59:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB57x5MN001263 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 02:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASArg-0000KE-2U for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 02:59: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 CAA24930 for ; Fri, 5 Dec 2003 02:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASArc-0004PH-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 02:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASArb-0004PE-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 02: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 1ASArd-0000JH-MS; Fri, 05 Dec 2003 02: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 1ASAqr-0000Hg-PY for rohc@optimus.ietf.org; Fri, 05 Dec 2003 02:58:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24900 for ; Fri, 5 Dec 2003 02:57:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASAqo-0004OW-00 for rohc@ietf.org; Fri, 05 Dec 2003 02:58:10 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ASAqn-0004OF-00 for rohc@ietf.org; Fri, 05 Dec 2003 02:58:09 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id hB56vQqP018963 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 5 Dec 2003 07:57:27 +0100 Message-ID: <3FD03A72.4030809@effnet.com> Date: Fri, 05 Dec 2003 08:57:38 +0100 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yousuf.Saifullah@nokia.com CC: lars-erik.jonsson@ericsson.com, mark.a.west@roke.co.uk, rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <025E7DD4182874489CC2F61EE0FA19CE01398929@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE01398929@daebe004.americas.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Yousuf! Sorry for not explaining clearly what I meant with my earlier answer. Here is a more detailed explanation: Regarding "small optimization", I agree that it is not minor if you save 20% off every header, but the question is how often this will occur without you already having a more suitable context to replicate from (i.e. one with an exact match). The context-replication-01 seems to target situations where you are opening multiple TCP connections from the same host, to the same server (such as web browsing). For this case, you will for all but the first flow get an exact match for at least one of the addresses (most often both). If you expect a lot of temporally close connections like this, then your savings will be a lot smaller. Note: We _could_ also take into account that you're using one extra bit of discriminator per address (i.e. 2 bits per packet per IP header). This will have a negative impact on compression if we have a very high percentage of exact matches and very seldom have partial matches. So my question would be: How many separate TCP connections do we expect the average user to open up in a short timespan? 1, 10, 100? When I have an _idea_ of that number, I will be able to say if your proposal makes sense technically. Right now, I can't really say. On the IPR issue, I would not like us to add IPR:ed solutions unless it is a really large gain, but let's wait and see what your IPR people say before we take that discussion further. Best regards, Kristofer Sandlund, Effnet AB Yousuf.Saifullah@nokia.com wrote: > Hi Lars-Erik, > > Thank you for your reply. > > >>This is not true, and answers so far have been rather >>skeptical to the idea, both because of the IPR and for >>technical reasons. >> > > For IPR reason, I have an update please see the last para of this email. For technical reasons, allow me to disagree. I still have to see an argument that this is not a good technical solution. In the emails by Mark and Kristofer, the concern was raised without any argument that why it is not a good technical solution. I gave the technical reasons/advantages, but I didn't see any response back. I am repeating here again, I would appreciate if someone could comment on the following and tell me why we are skeptical about savings from IP address compression (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt): > > Having same prefix in IP addresses, both in IPv4 and IPv6, is quite common and should be exploited for more compression. > > Let's take the first objection, "a very small optimization". This is not a small optimization. An IPv6 address is composed of 16 bytes, and there is a potential of saving many bytes from both source and destination addresses. If we assume that the subnet prefix is 64 bits, then it has potential of saving 8 bytes from an IP address. 8 byte saving is not a small optimization, if we consider 40 bytes of the total IPv6 header, then it is 20% saving on the raw IP header. If we consider TCP and IP header (60 bytes) it still gives 13.33% saving. > > Also, I have mentioned in my reply to Mark that this case is quite frequent to consider, I am repeating myself here with one more example: > - 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. > - Some networks, e.g. cellular, have IP terminals with same prefix indicating their gateways for their external networks. > - Corporate LAN environment has hosts with same prefix. In fact, any gateway based network would have same prefix for the hosts in its subnetwork. > > > >>Probably not. RAND-terms is usually not considered sufficient >>if an "IPR-free" solution is required. >> > > I have communicated the WG concern to my IPR folks that RAND-terms is not sufficient. They should be giving us more information soon. In the mean time, I would request to the WG to evaluate the IP address compression proposal technically. If technically it is found worthy of adoptation, but not found "IPR-free" we can drop the idea. But, if it also satisfies the IPR-free concern, then why not adopt it. It would provide more saving. > > 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 Fri Dec 5 05:02:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28649 for ; Fri, 5 Dec 2003 05:02: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 1ASCmi-0005RB-L1 for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 05:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5A24t7020895 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 05:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCmh-0005Qw-NZ for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 05: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 FAA28630 for ; Fri, 5 Dec 2003 05:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCme-0006DW-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 05:02:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASCme-0006DT-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 05:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCmf-0005Qg-Vw; Fri, 05 Dec 2003 05: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 1ASCmC-0005PL-Az for rohc@optimus.ietf.org; Fri, 05 Dec 2003 05:01: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 FAA28627 for ; Fri, 5 Dec 2003 05:01:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCm8-0006Bs-00 for rohc@ietf.org; Fri, 05 Dec 2003 05:01:28 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1ASCm8-0006Bj-00 for rohc@ietf.org; Fri, 05 Dec 2003 05:01:28 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 5 Dec 2003 10:00:58 -0000 Message-ID: From: "Surtees, Abigail" To: "'ksrini@comcast.net'" , rohc@ietf.org Subject: RE: UDVM - INPUT beyond message [was: RE: [rohc] input bytes beyo nd message ] Date: Fri, 5 Dec 2003 10:00:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 Srini, There was a conclusion (at IETF 56), which is included in section 3.1 of the implementer's guide http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-01.txt. You are right, the residual bytes would be available. Regards, Abbie > There was a discussion on the subject on this list. > What was decided?? Does anyone know. > Here is the pointer to the email-exchanges > > http://www1.ietf.org/mail-archive/working-groups/rohc/current/ msg01364.html RFC 3320 does not list any specifics in this regard. It says "If the instruction requests data that lies beyound the end of the SigComp message, no data is returned". Are the residual bytes in the input buffer - discarded? Or are they available for the next valid INPUT instruction? I guess they would be available right? Abigail Surtees Lajos Zaccomer One of you care to comment? Thanks very much -Srini _______________________________________________ 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 Dec 5 10:42:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10232 for ; Fri, 5 Dec 2003 10:42:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASI5i-0008HL-Q2 for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 10:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Fg2pO031817 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 10:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASI5i-0008H6-LG for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 10:42: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 KAA10218 for ; Fri, 5 Dec 2003 10:41:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASI5g-0002y1-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 10:42:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASI5f-0002xy-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 10:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASI5h-0008Gp-Cw; Fri, 05 Dec 2003 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASI4v-0008G9-Nh for rohc@optimus.ietf.org; Fri, 05 Dec 2003 10:41: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 KAA10203 for ; Fri, 5 Dec 2003 10:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASI4t-0002xd-00 for rohc@ietf.org; Fri, 05 Dec 2003 10:41:11 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ASI4s-0002xZ-00 for rohc@ietf.org; Fri, 05 Dec 2003 10:41:10 -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 hB5Ff8I2011219; Fri, 5 Dec 2003 16:41:09 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 5 Dec 2003 16:41:08 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Cho Chia Yuan'" Cc: rohc@ietf.org Subject: RE: [rohc] RE: Questions on Context Replication Date: Fri, 5 Dec 2003 16:40:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="Utf-8" 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: , > As you have mentioned in section 3.3.3.1 (starting from "Note > however... "), this problem probably exists, however remote > it is. I believe the key, then, lies in its significance - it > is a non-problem in current ROHC mechanisms without context > replication, because even without feedback, periodic > downwards transition to IR state is guaranteed to > resynchronize the decompressor context. If we add in context > replication, then without feedback, we may find that periodic > downwards transition to IR-CR state is not guaranteed to > resynchronize the decompressor context, because all base > contexts deemed valid at the compressor may be in > non-existence at the decompressor. Nothing is wrong in this analysis, but the above case will only appear if a decompressor invalidates a context on its own, without getting it overwritten by an instruction from the compressor. If someone does such an implementation, the implementer must be aware of and correctly handle the consequences. This is also what SHOULD mean, and therefore I agree with Ghyslains conclusion that SHOULD is still the right word. SHOULD means the same as MUST if you are doing a normal implementation. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 5 10:54:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10535 for ; Fri, 5 Dec 2003 10:54:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIHK-00008C-Tr for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 10:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Fs25p000498 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 10:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIHK-00007v-PV for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 10:54: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 KAA10522 for ; Fri, 5 Dec 2003 10:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASIHI-000364-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 10:54:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASIHH-000360-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 10:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIHJ-000077-95; Fri, 05 Dec 2003 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIHA-00006R-Bq for rohc@optimus.ietf.org; Fri, 05 Dec 2003 10:53:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10517 for ; Fri, 5 Dec 2003 10:53:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASIH7-00035r-00 for rohc@ietf.org; Fri, 05 Dec 2003 10:53:49 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ASIH7-00035o-00 for rohc@ietf.org; Fri, 05 Dec 2003 10:53:49 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB5FriSs006984; Fri, 5 Dec 2003 16:53:48 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 5 Dec 2003 16:53:44 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Yousuf.Saifullah@nokia.com'" Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Fri, 5 Dec 2003 16:53:13 +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: , > > This is not true, and answers so far have been rather > > skeptical to the idea, both because of the IPR and for > > technical reasons. > > > For IPR reason, I have an update please see the last para of > this email. For technical reasons, allow me to disagree. I > still have to see an argument that this is not a good > technical solution. It might be useful in some cases, but there always a trade-off. How much do you gain, in what cases, and how often are these cases expected to happen. Further, are there other mechanisms that will help is these cases. As also noted in Kristofers mail, the cases when this will have positive impact are not that many, and considering that we already have context replication reduces the relative gain even more. We have tried to make context replication simple, and for that reason I think this proposal is not important enough. The IPR is of course also an important factor. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 5 10:58:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10705 for ; Fri, 5 Dec 2003 10:58:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASILC-0000O7-FC for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 10:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Fw2pe001485 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 10: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 1ASILC-0000Na-AQ for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 10: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 KAA10666 for ; Fri, 5 Dec 2003 10:57:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASIL9-00039V-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 10:57:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASIL9-00039S-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 10: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 1ASILA-0000M4-HO; Fri, 05 Dec 2003 10: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 1ASAik-0008VB-4b for rohc@optimus.ietf.org; Fri, 05 Dec 2003 02:49:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24544 for ; Fri, 5 Dec 2003 02:49:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASAig-0004F4-00 for rohc@ietf.org; Fri, 05 Dec 2003 02:49:46 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ASAif-0004F1-00 for rohc@ietf.org; Fri, 05 Dec 2003 02:49:46 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB57njI2027749; Fri, 5 Dec 2003 08:49:45 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 5 Dec 2003 08:50:15 +0100 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: "'ksrini@comcast.net'" , rohc@ietf.org Subject: RE: UDVM - INPUT beyond message [was: RE: [rohc] input bytes beyo nd message ] Date: Fri, 5 Dec 2003 08:51:14 +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 Srini, I'm sure you'll find satisfactory answers to your questions (this one and of your next mail) in http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-01.txt BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ksrini@comcast.net Sent: Thursday, December 04, 2003 8:49 PM To: rohc@ietf.org Subject: UDVM - INPUT beyond message [was: RE: [rohc] input bytes beyond message ] There was a discussion on the subject on this list. What was decided?? Does anyone know. Here is the pointer to the email-exchanges http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01364.html RFC 3320 does not list any specifics in this regard. It says "If the instruction requests data that lies beyound the end of the SigComp message, no data is returned". Are the residual bytes in the input buffer - discarded? Or are they available for the next valid INPUT instruction? I guess they would be available right? Abigail Surtees Lajos Zaccomer One of you care to comment? Thanks very much -Srini _______________________________________________ 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 Dec 5 11:08:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11144 for ; Fri, 5 Dec 2003 11:08: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 1ASIUu-0001Bz-Cn for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 11:08:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5G83KH004508 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 11:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIUs-00019e-RU for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 11:08: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 LAA11109 for ; Fri, 5 Dec 2003 11:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASIUq-0003L2-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 11:08:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASIUp-0003Kz-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 11:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIUr-00018f-5T; Fri, 05 Dec 2003 11:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIUI-0000y9-SI for rohc@optimus.ietf.org; Fri, 05 Dec 2003 11:07:26 -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 LAA11089 for ; Fri, 5 Dec 2003 11:07:09 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ASIQZ-0001H5-Qu; Fri, 05 Dec 2003 11:03:35 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: rohc@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Fri, 05 Dec 2003 11:03:35 -0500 Subject: [rohc] Last Call: 'Definitions of Managed Objects for Robus Header Compression' to Proposed Standard Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Robust Header Compression WG to consider the following documents: - 'Definitions of Managed Objects for Robus Header Compression ' as a Proposed Standard - 'RObust Header Compression (ROHC):Terminology and Channel Mapping Examples ' as an Informational RFC 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-12-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-mib-rtp-08.txt http://www.ietf.org/internet-drafts/draft-ietf-rohc-terminology-and-examples-0 2.txt _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 5 14:08:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19101 for ; Fri, 5 Dec 2003 14:08: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 1ASLJ7-0000xT-Cq for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 14:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5J85d5003677 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 14:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASLJ6-0000x6-O3 for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 14:08: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 OAA19078 for ; Fri, 5 Dec 2003 14:07:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASLJ4-0000BQ-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 14:08:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASLJ3-0000BN-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 14:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASLJ3-0000vk-UY; Fri, 05 Dec 2003 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASLIy-0000uS-7n for rohc@optimus.ietf.org; Fri, 05 Dec 2003 14:07:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19069 for ; Fri, 5 Dec 2003 14:07:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASLIv-0000BD-00 for rohc@ietf.org; Fri, 05 Dec 2003 14:07:53 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1ASLIv-0000BA-00 for rohc@ietf.org; Fri, 05 Dec 2003 14:07:53 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hB5J7pGB019590 for ; Fri, 5 Dec 2003 12:07:52 -0700 (MST) Received: from bulb ([10.14.25.99]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id hB5J7Shi015483 for ; Fri, 5 Dec 2003 13:07:29 -0600 Date: Fri, 5 Dec 2003 14:07:28 -0500 (EST) From: Srinivasan Krishnamoorthy X-Sender: ksrini@bulb.corp.mot.com Reply-To: ksrini@motorola.com To: rohc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] Sigcomp Torture Test draft - LOAD and MULTILOAD 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, Have a question on the Load and MULTILOAD test case 2.5 from 'draft-price-rohc-sigcomp-torture-tests-02.txt' draft. The listed expected output '0x0084 0084 0086 0086 002a 0080 002a 002a' for test case 2.5 (LOAD and MULTILOAD) doesn't seem to be correct. If the input is '0x00' then the assembly, translates to LOAD(128,132), 0084 LOAD(130,132) 0084 LOAD(132,134) 0086 LOAD(134,134) 0086 OUTPUT(128, 8) --> outputs 0084 0084 0086 0086 INPUT_BYTES() ... MULTIPLY ... ADD ... MULTILOAD(60, 3, ...) [$start == 128.] From this point on location_a and location_b are not changed at all.. so the second multiload and the following output look like:- MULTILOAD(128, 4, 42, 128, $loc_a=132, $loc_b=134) OUTPUT(128,8) --> should output 002a 0080 0084 0086 The last 4 bytes are not (002a 002a). instead: they should be (0084 0086) right? Could some one help me clear this up ? thanks very much. -Srini The assembly code from the draft for this: at (64) :start pad (1) :start_lsb pad (1) at (128) set (location_a, 128) set (location_b, 132) LOAD (128, 132) LOAD (130, $location_a) LOAD ($location_a, 134) LOAD ($location_b, $location_b) OUTPUT (128, 8) INPUT-BYTES (1, start_lsb, !) MULTIPLY ($start, 2) ADD ($start, 60) MULTILOAD ($start, 3, overlap_start, overlap_end, 128) :position set (overlap_start, (position - 7)) MULTILOAD ($start, 4, 42, 128, $location_a, $location_b) :end set (overlap_end, (end - 1)) OUTPUT (128, 8) _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 5 16:00:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26518 for ; Fri, 5 Dec 2003 16:00: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 1ASN3X-0005a2-5Z for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 16:00:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5L07xj021451 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 16:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN3W-0005Zt-D2 for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 16:00: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 PAA26480 for ; Fri, 5 Dec 2003 15:59:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASN3U-0002RW-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16:00:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASN3U-0002RT-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16: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 1ASN3U-0005ZW-SH; Fri, 05 Dec 2003 16:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN3B-0005Y4-C9 for rohc@optimus.ietf.org; Fri, 05 Dec 2003 15:59: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 PAA26459 for ; Fri, 5 Dec 2003 15:59: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 1ASN39-0002Qs-00 for rohc@ietf.org; Fri, 05 Dec 2003 15:59:43 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ASN38-0002Qp-00 for rohc@ietf.org; Fri, 05 Dec 2003 15:59:43 -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 hB5Kxf113549 for ; Fri, 5 Dec 2003 22:59:42 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Dec 2003 22:59:41 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 14:59: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 Subject: RE: [rohc] IP Address Compression for Context Replication X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 5 Dec 2003 15:59:38 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E901@ajebe001.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO7BbLbLF90EL1VQJCSYVME8riGVAAYsG9w To: , Cc: , , X-OriginalArrivalTime: 05 Dec 2003 20:59:39.0683 (UTC) FILETIME=[B2CB2730:01C3BB72] 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 Kristofer, I'd like to throw in some comments if I may. You've raised a valid question: what would be the gain and cost? I'll try to answer that in different cases below. The first case, as you mentioned below, is that the a client opens multiple TCP connections from the same source IP address to the same server (i.e. dst address). Even in this case, our proposal allows the=20 compression of the IP addresses of the first connection, since the IP addresses within the same subnet have same prefix. Assuming IPv6 and n multiple TCP connections, the cost =3D 1*n bits (for the src IP = address) the gain =3D 64 bits. So the benefit/cost ratio =3D 64/n.=20 (Note I've already made conservative estimate about the gain, since the=20 prefix mathcing of IP address could be much longer than 64 bits in = practice.) Now let's compare that to the handling of TCP source port in tcp-05 I-D. = The cost =3D 2*n bits, the gain =3D 8*n bits =3D=3D> benefit/cost ratio =3D = 4. Compare this to the above, I don't see our prosal is a "small optimization" even = assuming we have 16 multiple connections between the same (source IP, = dest IP). Futhermore, for HTTP 1.1, a client SHOULD implement persistent = connections. That means n should be closer to 1, if not equal. So, the benefit/cost = ratio of our proposal is much larger than those already exists in tcp-05.=20 There are also other usage cases. For example, due to security/privacy = reasons,=20 a client may want to use different IP addresses to connect to servers = (even=20 the same one).=20 Lastly, note that our proposal is not only aimed at TCP HC. It can be = used as a general way to share context between packet flows within a subnet. In one extreme case for IPv6, a rounter can even just use one context to compress addresses for all the nodes within the subnet. That simplifies the logic and reduces CPU/memory cost, while focusing on the biggest part of IPv6 header (32 out of 40 bytes). BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Kristofer Sandlund > Sent: December 05, 2003 01:58 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; > rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Yousuf! >=20 > Sorry for not explaining clearly what I meant with my earlier=20 > answer. Here is a=20 > more detailed explanation: >=20 > Regarding "small optimization", I agree that it is not minor=20 > if you save 20% off=20 > every header, but the question is how often this will occur=20 > without you already=20 > having a more suitable context to replicate from (i.e. one=20 > with an exact match). > The context-replication-01 seems to target situations where=20 > you are opening=20 > multiple TCP connections from the same host, to the same=20 > server (such as web=20 > browsing). For this case, you will for all but the first flow=20 > get an exact match=20 > for at least one of the addresses (most often both). If you=20 > expect a lot of=20 > temporally close connections like this, then your savings=20 > will be a lot smaller. >=20 > Note: We _could_ also take into account that you're using one=20 > extra bit of=20 > discriminator per address (i.e. 2 bits per packet per IP=20 > header). This will=20 > have a negative impact on compression if we have a very high=20 > percentage of exact=20 > matches and very seldom have partial matches. >=20 > So my question would be: How many separate TCP connections do=20 > we expect the=20 > average user to open up in a short timespan? 1, 10, 100? > When I have an _idea_ of that number, I will be able to say=20 > if your proposal=20 > makes sense technically. Right now, I can't really say. >=20 >=20 > On the IPR issue, I would not like us to add IPR:ed solutions=20 > unless it is a=20 > really large gain, but let's wait and see what your IPR=20 > people say before we=20 > take that discussion further. >=20 > Best regards, > Kristofer Sandlund, Effnet AB >=20 > Yousuf.Saifullah@nokia.com wrote: > > Hi Lars-Erik, > >=20 > > Thank you for your reply.=20 > >=20 > >=20 > >>This is not true, and answers so far have been rather > >>skeptical to the idea, both because of the IPR and for > >>technical reasons. > >> > >=20 > > For IPR reason, I have an update please see the last para=20 > of this email. For technical reasons, allow me to disagree. I=20 > still have to see an argument that this is not a good=20 > technical solution. In the emails by Mark and Kristofer, the=20 > concern was raised without any argument that why it is not a=20 > good technical solution. I gave the technical=20 > reasons/advantages, but I didn't see any response back. I am=20 > repeating here again, I would appreciate if someone could=20 > comment on the following and tell me why we are skeptical=20 > about savings from IP address compression=20 > (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt): > >=20 > > Having same prefix in IP addresses, both in IPv4 and IPv6,=20 > is quite common and should be exploited for more compression.=20 > >=20 > > Let's take the first objection, "a very small=20 > optimization". This is not a small optimization. An IPv6=20 > address is composed of 16 bytes, and there is a potential of=20 > saving many bytes from both source and destination addresses.=20 > If we assume that the subnet prefix is 64 bits, then it has=20 > potential of saving 8 bytes from an IP address. 8 byte saving=20 > is not a small optimization, if we consider 40 bytes of the=20 > total IPv6 header, then it is 20% saving on the raw IP=20 > header. If we consider TCP and IP header (60 bytes) it still=20 > gives 13.33% saving.=20 > >=20 > > Also, I have mentioned in my reply to Mark that this case=20 > is quite frequent to consider, I am repeating myself here=20 > with one more example: > > - One case is mobile router, e.g. a train connected through=20 > a mobile router to an external network. In this case the IP=20 > addresses can be temporally close. > > - Another case is Personal Area Network, e.g. a person=20 > carrying a group of bluetooth devices which are connected via=20 > a mobile phone to an external network. In this case also the=20 > IP addresses will be temporally close.=20 > > - Some networks, e.g. cellular, have IP terminals with same=20 > prefix indicating their gateways for their external networks. > > - Corporate LAN environment has hosts with same prefix. In=20 > fact, any gateway based network would have same prefix for=20 > the hosts in its subnetwork.=20 > >=20 > >=20 > >=20 > >>Probably not. RAND-terms is usually not considered sufficient > >>if an "IPR-free" solution is required. > >> > >=20 > > I have communicated the WG concern to my IPR folks that=20 > RAND-terms is not sufficient. They should be giving us more=20 > information soon. In the mean time, I would request to the WG=20 > to evaluate the IP address compression proposal technically.=20 > If technically it is found worthy of adoptation, but not=20 > found "IPR-free" we can drop the idea. But, if it also=20 > satisfies the IPR-free concern, then why not adopt it. It=20 > would provide more saving. =20 > >=20 > > Regards, > > Yousuf > >=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 Fri Dec 5 16:22:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27177 for ; Fri, 5 Dec 2003 16: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 1ASNOl-0006kD-HU for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 16:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5LM3oW025919 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 16:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNOl-0006jy-Bw for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 16:22: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 QAA27159 for ; Fri, 5 Dec 2003 16:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNOj-0002j6-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16:22:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASNOj-0002j3-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNOj-0006ji-W2; Fri, 05 Dec 2003 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNOT-0006jQ-Es for rohc@optimus.ietf.org; Fri, 05 Dec 2003 16:21: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 QAA27152 for ; Fri, 5 Dec 2003 16:21: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 1ASNOR-0002in-00 for rohc@ietf.org; Fri, 05 Dec 2003 16:21:43 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ASNOQ-0002ik-00 for rohc@ietf.org; Fri, 05 Dec 2003 16:21:43 -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 hB5LLg103356 for ; Fri, 5 Dec 2003 23:21:42 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Dec 2003 23:21:40 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 13:21:38 -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: FW: [rohc] IP Address Compression for Context Replication X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 5 Dec 2003 16:21:36 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B80F1E87@ajebe001.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO7BbLbLF90EL1VQJCSYVME8riGVAAYsG9wAAM6/RA= To: , Cc: , , X-OriginalArrivalTime: 05 Dec 2003 21:21:38.0448 (UTC) FILETIME=[C4D6B900:01C3BB75] 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 One small correction (sorry about this): > Now let's compare that to the handling of TCP source port in tcp-05 = I-D. The > cost =3D 2*n bits, the gain =3D 8*n bits =3D=3D> benefit/cost ratio = =3D 4. The gain should be 8*(n-1) =3D=3D> benefit/cost ratio =3D 4*(n-1)/n. BR, Zhigang -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext zhigang.c.liu@nokia.com Sent: December 05, 2003 03:00 PM To: kristofer.sandlund@effnet.com; Saifullah Yousuf (NRC/Dallas) Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Hi Kristofer, I'd like to throw in some comments if I may. You've raised a valid question: what would be the gain and cost? I'll try to answer that in different cases below. The first case, as you mentioned below, is that the a client opens multiple TCP connections from the same source IP address to the same server (i.e. dst address). Even in this case, our proposal allows the=20 compression of the IP addresses of the first connection, since the IP addresses within the same subnet have same prefix. Assuming IPv6 and n multiple TCP connections, the cost =3D 1*n bits (for the src IP = address) the gain =3D 64 bits. So the benefit/cost ratio =3D 64/n.=20 (Note I've already made conservative estimate about the gain, since the=20 prefix mathcing of IP address could be much longer than 64 bits in = practice.) Now let's compare that to the handling of TCP source port in tcp-05 I-D. = The cost =3D 2*n bits, the gain =3D 8*n bits =3D=3D> benefit/cost ratio =3D = 4. Compare this to the above, I don't see our prosal is a "small optimization" even = assuming we have 16 multiple connections between the same (source IP, = dest IP). Futhermore, for HTTP 1.1, a client SHOULD implement persistent = connections. That means n should be closer to 1, if not equal. So, the benefit/cost = ratio of our proposal is much larger than those already exists in tcp-05.=20 There are also other usage cases. For example, due to security/privacy = reasons,=20 a client may want to use different IP addresses to connect to servers = (even=20 the same one).=20 Lastly, note that our proposal is not only aimed at TCP HC. It can be = used as a general way to share context between packet flows within a subnet. In one extreme case for IPv6, a rounter can even just use one context to compress addresses for all the nodes within the subnet. That simplifies the logic and reduces CPU/memory cost, while focusing on the biggest part of IPv6 header (32 out of 40 bytes). BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Kristofer Sandlund > Sent: December 05, 2003 01:58 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; > rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Yousuf! >=20 > Sorry for not explaining clearly what I meant with my earlier=20 > answer. Here is a=20 > more detailed explanation: >=20 > Regarding "small optimization", I agree that it is not minor=20 > if you save 20% off=20 > every header, but the question is how often this will occur=20 > without you already=20 > having a more suitable context to replicate from (i.e. one=20 > with an exact match). > The context-replication-01 seems to target situations where=20 > you are opening=20 > multiple TCP connections from the same host, to the same=20 > server (such as web=20 > browsing). For this case, you will for all but the first flow=20 > get an exact match=20 > for at least one of the addresses (most often both). If you=20 > expect a lot of=20 > temporally close connections like this, then your savings=20 > will be a lot smaller. >=20 > Note: We _could_ also take into account that you're using one=20 > extra bit of=20 > discriminator per address (i.e. 2 bits per packet per IP=20 > header). This will=20 > have a negative impact on compression if we have a very high=20 > percentage of exact=20 > matches and very seldom have partial matches. >=20 > So my question would be: How many separate TCP connections do=20 > we expect the=20 > average user to open up in a short timespan? 1, 10, 100? > When I have an _idea_ of that number, I will be able to say=20 > if your proposal=20 > makes sense technically. Right now, I can't really say. >=20 >=20 > On the IPR issue, I would not like us to add IPR:ed solutions=20 > unless it is a=20 > really large gain, but let's wait and see what your IPR=20 > people say before we=20 > take that discussion further. >=20 > Best regards, > Kristofer Sandlund, Effnet AB >=20 > Yousuf.Saifullah@nokia.com wrote: > > Hi Lars-Erik, > >=20 > > Thank you for your reply.=20 > >=20 > >=20 > >>This is not true, and answers so far have been rather > >>skeptical to the idea, both because of the IPR and for > >>technical reasons. > >> > >=20 > > For IPR reason, I have an update please see the last para=20 > of this email. For technical reasons, allow me to disagree. I=20 > still have to see an argument that this is not a good=20 > technical solution. In the emails by Mark and Kristofer, the=20 > concern was raised without any argument that why it is not a=20 > good technical solution. I gave the technical=20 > reasons/advantages, but I didn't see any response back. I am=20 > repeating here again, I would appreciate if someone could=20 > comment on the following and tell me why we are skeptical=20 > about savings from IP address compression=20 > (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt): > >=20 > > Having same prefix in IP addresses, both in IPv4 and IPv6,=20 > is quite common and should be exploited for more compression.=20 > >=20 > > Let's take the first objection, "a very small=20 > optimization". This is not a small optimization. An IPv6=20 > address is composed of 16 bytes, and there is a potential of=20 > saving many bytes from both source and destination addresses.=20 > If we assume that the subnet prefix is 64 bits, then it has=20 > potential of saving 8 bytes from an IP address. 8 byte saving=20 > is not a small optimization, if we consider 40 bytes of the=20 > total IPv6 header, then it is 20% saving on the raw IP=20 > header. If we consider TCP and IP header (60 bytes) it still=20 > gives 13.33% saving.=20 > >=20 > > Also, I have mentioned in my reply to Mark that this case=20 > is quite frequent to consider, I am repeating myself here=20 > with one more example: > > - One case is mobile router, e.g. a train connected through=20 > a mobile router to an external network. In this case the IP=20 > addresses can be temporally close. > > - Another case is Personal Area Network, e.g. a person=20 > carrying a group of bluetooth devices which are connected via=20 > a mobile phone to an external network. In this case also the=20 > IP addresses will be temporally close.=20 > > - Some networks, e.g. cellular, have IP terminals with same=20 > prefix indicating their gateways for their external networks. > > - Corporate LAN environment has hosts with same prefix. In=20 > fact, any gateway based network would have same prefix for=20 > the hosts in its subnetwork.=20 > >=20 > >=20 > >=20 > >>Probably not. RAND-terms is usually not considered sufficient > >>if an "IPR-free" solution is required. > >> > >=20 > > I have communicated the WG concern to my IPR folks that=20 > RAND-terms is not sufficient. They should be giving us more=20 > information soon. In the mean time, I would request to the WG=20 > to evaluate the IP address compression proposal technically.=20 > If technically it is found worthy of adoptation, but not=20 > found "IPR-free" we can drop the idea. But, if it also=20 > satisfies the IPR-free concern, then why not adopt it. It=20 > would provide more saving. =20 > >=20 > > Regards, > > Yousuf > >=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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 5 16:43:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28281 for ; Fri, 5 Dec 2003 16: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 1ASNj5-0007aU-PJ for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 16:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Lh3gI029160 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 16: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 1ASNj5-0007aF-F8 for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 16: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 QAA28263 for ; Fri, 5 Dec 2003 16:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNj3-0004mu-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASNj2-0004mo-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNj3-0007Zp-H1; Fri, 05 Dec 2003 16: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 1ASNix-0007ZT-Ve for rohc@optimus.ietf.org; Fri, 05 Dec 2003 16:42:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28247 for ; Fri, 5 Dec 2003 16:42:40 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNiv-0004kU-00 for rohc@ietf.org; Fri, 05 Dec 2003 16:42:53 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ASNiv-0004k4-00 for rohc@ietf.org; Fri, 05 Dec 2003 16:42:53 -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 hB5Lgr122289 for ; Fri, 5 Dec 2003 23:42:53 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Dec 2003 23:42:53 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 15:42:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Fri, 5 Dec 2003 15:42:50 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139892E@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO7R/r81p5tzY00RXKVNpqYBUVgDgALib3w To: Cc: X-OriginalArrivalTime: 05 Dec 2003 21:42:51.0825 (UTC) FILETIME=[BBD4A210:01C3BB78] 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 Lars-Erik, Thanks for the reply. Zhigang has given a good analysis of how much we = can gain. He also compared with the port # compression, which also has = two bits of discriminator. I think 2 bits of IP address discriminator = are more justified than the port #s. I don't think there are other = mechanisms for providing IP address compression in context replication.=20 Kristofer compared with the case where one host has multiple TCP = connection with the same server (web browsing). I disagree that we = should target context replication for the cases where one host creates = multiple TCP connection with the same server. First, this is not a = frequent case with HTTP 1.1, they provide persistent TCP connection. = Second, IP Address compression is not limited to TCP and it could be = applied to the other profiles supporting context replication. If I = compare the Kristofer case with the cases I have mentioned, my cases are = more frequent.=20 Could you please clarify why it is not simple technically. We are only = matching run length for IP address compression. Thanks, Yousuf=20 > -----Original Message----- > From: ext Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Friday, December 05, 2003 9:53 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > > > This is not true, and answers so far have been rather > > > skeptical to the idea, both because of the IPR and for > > > technical reasons. > > >=20 > > For IPR reason, I have an update please see the last para of=20 > > this email. For technical reasons, allow me to disagree. I=20 > > still have to see an argument that this is not a good=20 > > technical solution.=20 >=20 > It might be useful in some cases, but there always a trade-off. > How much do you gain, in what cases, and how often are these > cases expected to happen. Further, are there other mechanisms > that will help is these cases. >=20 > As also noted in Kristofers mail, the cases when this will > have positive impact are not that many, and considering that > we already have context replication reduces the relative gain > even more. We have tried to make context replication simple, > and for that reason I think this proposal is not important > enough. >=20 > The IPR is of course also an important factor. >=20 > /L-E >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 5 16:48:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28414 for ; Fri, 5 Dec 2003 16:48:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNoW-0007hv-DS for rohc-archive@odin.ietf.org; Fri, 05 Dec 2003 16:48:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5LmeJt029617 for rohc-archive@odin.ietf.org; Fri, 5 Dec 2003 16:48:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNoW-0007hb-5h for rohc-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 16:48:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28392 for ; Fri, 5 Dec 2003 16:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNoT-0005KV-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16:48:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASNoS-00059H-00 for rohc-web-archive@ietf.org; Fri, 05 Dec 2003 16:48:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNnt-0007fO-1Q; Fri, 05 Dec 2003 16: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 1ASNnc-0007ez-KW for rohc@optimus.ietf.org; Fri, 05 Dec 2003 16:47: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 QAA28362 for ; Fri, 5 Dec 2003 16:47:28 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNna-00057o-00 for rohc@ietf.org; Fri, 05 Dec 2003 16:47:42 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ASNnZ-00057h-00 for rohc@ietf.org; Fri, 05 Dec 2003 16:47:41 -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 hB5Llf126605 for ; Fri, 5 Dec 2003 23:47:41 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Dec 2003 23:47:41 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 15:47:06 -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: Fri, 5 Dec 2003 15:47:05 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0121DDEE@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO7BY1vlBs0VmJLTkuge1LSshdAsAAc0lTA To: Cc: , , X-OriginalArrivalTime: 05 Dec 2003 21:47:06.0326 (UTC) FILETIME=[53866760:01C3BB79] 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 Kristofer, I would like to answer the question in your email. For the comments = regarding other parts of your email, please see the last two emails on = this subject. Thanks, Yousuf > -----Original Message----- > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: Friday, December 05, 2003 1:58 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; > rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Yousuf! >=20 > Sorry for not explaining clearly what I meant with my earlier=20 > answer. Here is a=20 > more detailed explanation: >=20 > Regarding "small optimization", I agree that it is not minor=20 > if you save 20% off=20 > every header, but the question is how often this will occur=20 > without you already=20 > having a more suitable context to replicate from (i.e. one=20 > with an exact match). > The context-replication-01 seems to target situations where=20 > you are opening=20 > multiple TCP connections from the same host, to the same=20 > server (such as web=20 > browsing). For this case, you will for all but the first flow=20 > get an exact match=20 > for at least one of the addresses (most often both). If you=20 > expect a lot of=20 > temporally close connections like this, then your savings=20 > will be a lot smaller. >=20 > Note: We _could_ also take into account that you're using one=20 > extra bit of=20 > discriminator per address (i.e. 2 bits per packet per IP=20 > header). This will=20 > have a negative impact on compression if we have a very high=20 > percentage of exact=20 > matches and very seldom have partial matches. >=20 > So my question would be: How many separate TCP connections do=20 > we expect the=20 > average user to open up in a short timespan? 1, 10, 100? > When I have an _idea_ of that number, I will be able to say=20 > if your proposal=20 > makes sense technically. Right now, I can't really say. >=20 If you are asking TCP connection between one user and one server, then = the answer is 1 with HTTP 1.1. >=20 > On the IPR issue, I would not like us to add IPR:ed solutions=20 > unless it is a=20 > really large gain, but let's wait and see what your IPR=20 > people say before we=20 > take that discussion further. >=20 > Best regards, > Kristofer Sandlund, Effnet AB >=20 > Yousuf.Saifullah@nokia.com wrote: > > Hi Lars-Erik, > >=20 > > Thank you for your reply.=20 > >=20 > >=20 > >>This is not true, and answers so far have been rather > >>skeptical to the idea, both because of the IPR and for > >>technical reasons. > >> > >=20 > > For IPR reason, I have an update please see the last para=20 > of this email. For technical reasons, allow me to disagree. I=20 > still have to see an argument that this is not a good=20 > technical solution. In the emails by Mark and Kristofer, the=20 > concern was raised without any argument that why it is not a=20 > good technical solution. I gave the technical=20 > reasons/advantages, but I didn't see any response back. I am=20 > repeating here again, I would appreciate if someone could=20 > comment on the following and tell me why we are skeptical=20 > about savings from IP address compression=20 > (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt): > >=20 > > Having same prefix in IP addresses, both in IPv4 and IPv6,=20 > is quite common and should be exploited for more compression.=20 > >=20 > > Let's take the first objection, "a very small=20 > optimization". This is not a small optimization. An IPv6=20 > address is composed of 16 bytes, and there is a potential of=20 > saving many bytes from both source and destination addresses.=20 > If we assume that the subnet prefix is 64 bits, then it has=20 > potential of saving 8 bytes from an IP address. 8 byte saving=20 > is not a small optimization, if we consider 40 bytes of the=20 > total IPv6 header, then it is 20% saving on the raw IP=20 > header. If we consider TCP and IP header (60 bytes) it still=20 > gives 13.33% saving.=20 > >=20 > > Also, I have mentioned in my reply to Mark that this case=20 > is quite frequent to consider, I am repeating myself here=20 > with one more example: > > - One case is mobile router, e.g. a train connected through=20 > a mobile router to an external network. In this case the IP=20 > addresses can be temporally close. > > - Another case is Personal Area Network, e.g. a person=20 > carrying a group of bluetooth devices which are connected via=20 > a mobile phone to an external network. In this case also the=20 > IP addresses will be temporally close.=20 > > - Some networks, e.g. cellular, have IP terminals with same=20 > prefix indicating their gateways for their external networks. > > - Corporate LAN environment has hosts with same prefix. In=20 > fact, any gateway based network would have same prefix for=20 > the hosts in its subnetwork.=20 > >=20 > >=20 > >=20 > >>Probably not. RAND-terms is usually not considered sufficient > >>if an "IPR-free" solution is required. > >> > >=20 > > I have communicated the WG concern to my IPR folks that=20 > RAND-terms is not sufficient. They should be giving us more=20 > information soon. In the mean time, I would request to the WG=20 > to evaluate the IP address compression proposal technically.=20 > If technically it is found worthy of adoptation, but not=20 > found "IPR-free" we can drop the idea. But, if it also=20 > satisfies the IPR-free concern, then why not adopt it. It=20 > would provide more saving. =20 > >=20 > > Regards, > > Yousuf > >=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 From exim@www1.ietf.org Sat Dec 6 22:19:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29724 for ; Sat, 6 Dec 2003 22:19: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 1ASpRm-0007rz-Uo for rohc-archive@odin.ietf.org; Sat, 06 Dec 2003 22:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB73J2YX030245 for rohc-archive@odin.ietf.org; Sat, 6 Dec 2003 22:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASpRm-0007rk-QC for rohc-web-archive@optimus.ietf.org; Sat, 06 Dec 2003 22:19: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 WAA29697 for ; Sat, 6 Dec 2003 22:18:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASpRj-0003Ei-00 for rohc-web-archive@ietf.org; Sat, 06 Dec 2003 22:18:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASpRj-0003Ee-00 for rohc-web-archive@ietf.org; Sat, 06 Dec 2003 22:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASpRk-0007rT-Iv; Sat, 06 Dec 2003 22:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASpRD-0007n5-HG for rohc@optimus.ietf.org; Sat, 06 Dec 2003 22:18: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 WAA29684 for ; Sat, 6 Dec 2003 22:18:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASpRA-0003E9-00 for rohc@ietf.org; Sat, 06 Dec 2003 22:18:24 -0500 Received: from mail-jpn.microsoft.com ([207.46.71.29]) by ietf-mx with esmtp (Exim 4.12) id 1ASpR9-0003E6-00 for rohc@ietf.org; Sat, 06 Dec 2003 22:18:23 -0500 Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 7 Dec 2003 12:18:16 +0900 Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 07 Dec 2003 12:18:16 +0900 Received: from BJS-MSG-01.fareast.corp.microsoft.com ([157.60.72.120]) by jpn-imc-01.fareast.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 7 Dec 2003 12:18:16 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Sun, 7 Dec 2003 11:18:14 +0800 Message-ID: Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO7BY1vlBs0VmJLTkuge1LSshdAsAAc0lTAAD2mL0E= From: "Qian Zhang \(MSR\)" To: , Cc: , , X-OriginalArrivalTime: 07 Dec 2003 03:18:16.0058 (UTC) FILETIME=[C138A5A0:01C3BC70] 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, =20 I agree with Lars-Erik's comments in his previous email, yes, we can = have many possible enhancements for context replication part, however, = it does not make lots of sense to add all them in. We should keep in mind that we need very careful when using context = replication technology. We need to make sure that the base context is = reliable enough before it can be reused. Thus, some simple and efficient = scheme is good enough for it.=20 It would make the ROHC-TCP profile too complicated if we introduce = another optinal for it.=20 Moreover, IPR issue is a big concern. Just to refresh everyone's memory, = the uni-directional enhancement technology had been removed from the = basic ROHC-TCP profile although it can bring much performance gain in = uni-directional scenario. =20 Best, Qian =20 ________________________________ From: rohc-admin@ietf.org on behalf of Yousuf.Saifullah@nokia.com Sent: Sat 12/6/2003 5:47 AM To: kristofer.sandlund@effnet.com Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; = rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Hi Kristofer, I would like to answer the question in your email. For the comments = regarding other parts of your email, please see the last two emails on = this subject. Thanks, Yousuf > -----Original Message----- > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: Friday, December 05, 2003 1:58 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; > rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication > > > Hi Yousuf! > > Sorry for not explaining clearly what I meant with my earlier > answer. Here is a > more detailed explanation: > > Regarding "small optimization", I agree that it is not minor > if you save 20% off > every header, but the question is how often this will occur > without you already > having a more suitable context to replicate from (i.e. one > with an exact match). > The context-replication-01 seems to target situations where > you are opening > multiple TCP connections from the same host, to the same > server (such as web > browsing). For this case, you will for all but the first flow > get an exact match > for at least one of the addresses (most often both). If you > expect a lot of > temporally close connections like this, then your savings > will be a lot smaller. > > Note: We _could_ also take into account that you're using one > extra bit of > discriminator per address (i.e. 2 bits per packet per IP > header). This will > have a negative impact on compression if we have a very high > percentage of exact > matches and very seldom have partial matches. > > So my question would be: How many separate TCP connections do > we expect the > average user to open up in a short timespan? 1, 10, 100? > When I have an _idea_ of that number, I will be able to say > if your proposal > makes sense technically. Right now, I can't really say. > If you are asking TCP connection between one user and one server, then = the answer is 1 with HTTP 1.1. > > On the IPR issue, I would not like us to add IPR:ed solutions > unless it is a > really large gain, but let's wait and see what your IPR > people say before we > take that discussion further. > > Best regards, > Kristofer Sandlund, Effnet AB > > Yousuf.Saifullah@nokia.com wrote: > > Hi Lars-Erik, > > > > Thank you for your reply. > > > > > >>This is not true, and answers so far have been rather > >>skeptical to the idea, both because of the IPR and for > >>technical reasons. > >> > > > > For IPR reason, I have an update please see the last para > of this email. For technical reasons, allow me to disagree. I > still have to see an argument that this is not a good > technical solution. In the emails by Mark and Kristofer, the > concern was raised without any argument that why it is not a > good technical solution. I gave the technical > reasons/advantages, but I didn't see any response back. I am > repeating here again, I would appreciate if someone could > comment on the following and tell me why we are skeptical > about savings from IP address compression > (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt): > > > > Having same prefix in IP addresses, both in IPv4 and IPv6, > is quite common and should be exploited for more compression. > > > > Let's take the first objection, "a very small > optimization". This is not a small optimization. An IPv6 > address is composed of 16 bytes, and there is a potential of > saving many bytes from both source and destination addresses. > If we assume that the subnet prefix is 64 bits, then it has > potential of saving 8 bytes from an IP address. 8 byte saving > is not a small optimization, if we consider 40 bytes of the > total IPv6 header, then it is 20% saving on the raw IP > header. If we consider TCP and IP header (60 bytes) it still > gives 13.33% saving. > > > > Also, I have mentioned in my reply to Mark that this case > is quite frequent to consider, I am repeating myself here > with one more example: > > - 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. > > - Some networks, e.g. cellular, have IP terminals with same > prefix indicating their gateways for their external networks. > > - Corporate LAN environment has hosts with same prefix. In > fact, any gateway based network would have same prefix for > the hosts in its subnetwork. > > > > > > > >>Probably not. RAND-terms is usually not considered sufficient > >>if an "IPR-free" solution is required. > >> > > > > I have communicated the WG concern to my IPR folks that > RAND-terms is not sufficient. They should be giving us more > information soon. In the mean time, I would request to the WG > to evaluate the IP address compression proposal technically. > If technically it is found worthy of adoptation, but not > found "IPR-free" we can drop the idea. But, if it also > satisfies the IPR-free concern, then why not adopt it. It > would provide more saving.=20 > > > > 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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun Dec 7 09:49:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24513 for ; Sun, 7 Dec 2003 09:49:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT0DW-0006iD-BC for rohc-archive@odin.ietf.org; Sun, 07 Dec 2003 09:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7En2qL025797 for rohc-archive@odin.ietf.org; Sun, 7 Dec 2003 09:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT0DW-0006i0-84 for rohc-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 09:49: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 JAA24507 for ; Sun, 7 Dec 2003 09:48:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT0DU-0001qS-00 for rohc-web-archive@ietf.org; Sun, 07 Dec 2003 09:49:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AT0DT-0001qP-00 for rohc-web-archive@ietf.org; Sun, 07 Dec 2003 09:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT0DU-0006hg-UP; Sun, 07 Dec 2003 09:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT0D4-0006hQ-4R for rohc@optimus.ietf.org; Sun, 07 Dec 2003 09:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24495 for ; Sun, 7 Dec 2003 09:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT0D2-0001pz-00 for rohc@ietf.org; Sun, 07 Dec 2003 09:48:32 -0500 Received: from ims21.stu.nus.edu.sg ([137.132.14.228]) by ietf-mx with esmtp (Exim 4.12) id 1AT0D1-0001pu-00 for rohc@ietf.org; Sun, 07 Dec 2003 09:48:31 -0500 Received: from MBXSRV23.stu.nus.edu.sg ([137.132.14.233]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Sun, 7 Dec 2003 22:48:27 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 7 Dec 2003 22:48:27 +0800 Message-ID: <97B6AED9BBAE4845B2559DA63E6ECDC2032280B8@MBXSRV23.stu.nus.edu.sg> Thread-Topic: RE: Questions on Context Replication Thread-Index: AcO80SwyGJtpSXn0TgSfytsTOylo0A== From: "Cho Chia Yuan" To: , Cc: X-OriginalArrivalTime: 07 Dec 2003 14:48:27.0686 (UTC) FILETIME=[2C799C60:01C3BCD1] Content-Transfer-Encoding: base64 Subject: [rohc] RE: Questions on 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: base64 Content-Transfer-Encoding: base64 SGkgTGFycy1FcmlrIGFuZCBHaHlzbGFpbiwNCiANCklmIHRoZSBwcm9ibGVtIG1lbnRpb25lZCBp biBzZWN0aW9uIDMuMy4zLjEgY2FuIG9ubHkgYmUgY2F1c2VkIGJ5IGNlcnRhaW4gaW1wbGVtZW50 YXRpb25zLCB0aGVuIEkgYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBuZWVkIHRvIGhhdmUgYSBub24t aW1wbGVtZW50YXRpb24gZGVwZW5kZW50IHNvbHV0aW9uLiBUaHVzLCByZWdhcmRpbmcgZmVlZGJh Y2sgb2YgU1RBVElDLU5BQ0tzLCBJIGFncmVlIHRoYXQgU0hPVUxEIGlzIG1vcmUgYXBwcm9wcmlh dGUgdGhhbiBNVVNULg0KIA0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiENCiANClJlZ2Fy ZHMsDQpDaGlhIFl1YW4gQ2hvDQpOYXRpb25hbCBVbml2ZXJzaXR5IG9mIFNpbmdhcG9yZQ0KL0lu c3RpdHV0ZSBmb3IgSW5mb2NvbW0gUmVzZWFyY2gNCiANCiANCj4gQXMgeW91IGhhdmUgbWVudGlv bmVkIGluIHNlY3Rpb24gMy4zLjMuMSAoc3RhcnRpbmcgZnJvbSAiTm90ZQ0KPiBob3dldmVyLi4u ICIpLCB0aGlzIHByb2JsZW0gcHJvYmFibHkgZXhpc3RzLCBob3dldmVyIHJlbW90ZQ0KPiBpdCBp cy4gSSBiZWxpZXZlIHRoZSBrZXksIHRoZW4sIGxpZXMgaW4gaXRzIHNpZ25pZmljYW5jZSAtIGl0 DQo+IGlzIGEgbm9uLXByb2JsZW0gaW4gY3VycmVudCBST0hDIG1lY2hhbmlzbXMgd2l0aG91dCBj b250ZXh0DQo+IHJlcGxpY2F0aW9uLCBiZWNhdXNlIGV2ZW4gd2l0aG91dCBmZWVkYmFjaywgcGVy aW9kaWMNCj4gZG93bndhcmRzIHRyYW5zaXRpb24gdG8gSVIgc3RhdGUgaXMgZ3VhcmFudGVlZCB0 bw0KPiByZXN5bmNocm9uaXplIHRoZSBkZWNvbXByZXNzb3IgY29udGV4dC4gSWYgd2UgYWRkIGlu IGNvbnRleHQNCj4gcmVwbGljYXRpb24sIHRoZW4gd2l0aG91dCBmZWVkYmFjaywgd2UgbWF5IGZp bmQgdGhhdCBwZXJpb2RpYw0KPiBkb3dud2FyZHMgdHJhbnNpdGlvbiB0byBJUi1DUiBzdGF0ZSBp cyBub3QgZ3VhcmFudGVlZCB0bw0KPiByZXN5bmNocm9uaXplIHRoZSBkZWNvbXByZXNzb3IgY29u dGV4dCwgYmVjYXVzZSBhbGwgYmFzZQ0KPiBjb250ZXh0cyBkZWVtZWQgdmFsaWQgYXQgdGhlIGNv bXByZXNzb3IgbWF5IGJlIGluDQo+IG5vbi1leGlzdGVuY2UgYXQgdGhlIGRlY29tcHJlc3Nvci4N Cg0KTm90aGluZyBpcyB3cm9uZyBpbiB0aGlzIGFuYWx5c2lzLCBidXQgdGhlIGFib3ZlIGNhc2Ug d2lsbA0Kb25seSBhcHBlYXIgaWYgYSBkZWNvbXByZXNzb3IgaW52YWxpZGF0ZXMgYSBjb250ZXh0 IG9uIGl0cw0Kb3duLCB3aXRob3V0IGdldHRpbmcgaXQgb3ZlcndyaXR0ZW4gYnkgYW4gaW5zdHJ1 Y3Rpb24gZnJvbQ0KdGhlIGNvbXByZXNzb3IuIElmIHNvbWVvbmUgZG9lcyBzdWNoIGFuIGltcGxl bWVudGF0aW9uLCB0aGUNCmltcGxlbWVudGVyIG11c3QgYmUgYXdhcmUgb2YgYW5kIGNvcnJlY3Rs eSBoYW5kbGUgdGhlDQpjb25zZXF1ZW5jZXMuIFRoaXMgaXMgYWxzbyB3aGF0IFNIT1VMRCBtZWFu LCBhbmQgdGhlcmVmb3JlDQpJIGFncmVlIHdpdGggR2h5c2xhaW5zIGNvbmNsdXNpb24gdGhhdCBT SE9VTEQgaXMgc3RpbGwgdGhlDQpyaWdodCB3b3JkLiBTSE9VTEQgbWVhbnMgdGhlIHNhbWUgYXMg TVVTVCBpZiB5b3UgYXJlIGRvaW5nDQphIG5vcm1hbCBpbXBsZW1lbnRhdGlvbi4NCg0KL0wtRQ0K DQo= _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Dec 8 10:11:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12467 for ; Mon, 8 Dec 2003 10: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 1ATN2O-0001hy-Tz for rohc-archive@odin.ietf.org; Mon, 08 Dec 2003 10:11:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8FB40U006559 for rohc-archive@odin.ietf.org; Mon, 8 Dec 2003 10: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 1ATN2O-0001hi-Pc for rohc-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 10: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 KAA12409 for ; Mon, 8 Dec 2003 10:10:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATN2M-0005md-00 for rohc-web-archive@ietf.org; Mon, 08 Dec 2003 10:11:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATN2M-0005mZ-00 for rohc-web-archive@ietf.org; Mon, 08 Dec 2003 10:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATN2L-0001hG-UT; Mon, 08 Dec 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 1ATN1Q-0001gk-4S for rohc@optimus.ietf.org; Mon, 08 Dec 2003 10:10: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 KAA12307 for ; Mon, 8 Dec 2003 10:09:47 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATN1N-0005kk-00 for rohc@ietf.org; Mon, 08 Dec 2003 10:10:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATN1N-0005kg-00 for rohc@ietf.org; Mon, 08 Dec 2003 10:10:01 -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 hB8FA0x26981 for ; Mon, 8 Dec 2003 17:10:00 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Dec 2003 17:10:00 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 8 Dec 2003 07:09:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Mon, 8 Dec 2003 09:09:25 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139892F@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO7BY1vlBs0VmJLTkuge1LSshdAsAAc0lTAAD2mL0EASpykgA== To: , Cc: , , X-OriginalArrivalTime: 08 Dec 2003 15:09:26.0358 (UTC) FILETIME=[451D7760:01C3BD9D] 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 Qian, Thank you for your comments. I would also like to give an update that = the IPR status is changed to "non-assertive". An official statement will = appear soon. With this status Nokia is not going to assert its IPR and = anybody can implement it. Hopefully this would take away the IPR = concern. Please see my specific replies below. Please also comment on the emails = sent by me and Zhigang on Friday (USA time). Regards, Yousuf=20 > -----Original Message----- > From: ext Qian Zhang (MSR) [mailto:qianz@microsoft.com] > Sent: Saturday, December 06, 2003 9:18 PM > To: Saifullah Yousuf (NRC/Dallas); kristofer.sandlund@effnet.com > Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; > rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi all, > =20 > I agree with Lars-Erik's comments in his previous email, yes,=20 > we can have many possible enhancements for context=20 > replication part, however, it does not make lots of sense to=20 > add all them in. I also agree with you and Lars-Erik that we should add only those = enhancements which make sense. Zhigang has provided numbers to show the = savings in an email sent on last Friday. Please tell me why technically = it doesn't make sense to have IP address compression for CR? I was asked = to give cases and gain, and we have provided that. Kristofer compared it = with one host and one server TCP connections, and we replied it. We = should make decision on the basis of technical argument.=20 > We should keep in mind that we need very careful when using=20 > context replication technology. We need to make sure that the=20 > base context is reliable enough before it can be reused.=20 > Thus, some simple and efficient scheme is good enough for it.=20 > It would make the ROHC-TCP profile too complicated if we=20 > introduce another optinal for it.=20 I don't think that the IP Address compression for CR has any issue with = the reliability of the base. Could you please identify if you see any. I = have mentioned in an earlier email that how simple our proposal is. We = are only matching run length. Could you please support your above = statement with technical reasons why it is not simple and not efficient. > Moreover, IPR issue is a big concern. Just to refresh=20 > everyone's memory, the uni-directional enhancement technology=20 > had been removed from the basic ROHC-TCP profile although it=20 > can bring much performance gain in uni-directional scenario. > =20 I had understood the IPR concern, and had communicated it to the IPR = folks. They have changed the IPR status to "non-assertive".=20 > Best, > Qian > =20 >=20 > ________________________________ >=20 > From: rohc-admin@ietf.org on behalf of Yousuf.Saifullah@nokia.com > Sent: Sat 12/6/2003 5:47 AM > To: kristofer.sandlund@effnet.com > Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk;=20 > rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 >=20 > Hi Kristofer, > I would like to answer the question in your email. For the=20 > comments regarding other parts of your email, please see the=20 > last two emails on this subject. >=20 > Thanks, > Yousuf >=20 > > -----Original Message----- > > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > > Sent: Friday, December 05, 2003 1:58 AM > > To: Saifullah Yousuf (NRC/Dallas) > > Cc: lars-erik.jonsson@ericsson.com; mark.a.west@roke.co.uk; > > rohc@ietf.org > > Subject: Re: [rohc] IP Address Compression for Context Replication > > > > > > Hi Yousuf! > > > > Sorry for not explaining clearly what I meant with my earlier > > answer. Here is a > > more detailed explanation: > > > > Regarding "small optimization", I agree that it is not minor > > if you save 20% off > > every header, but the question is how often this will occur > > without you already > > having a more suitable context to replicate from (i.e. one > > with an exact match). > > The context-replication-01 seems to target situations where > > you are opening > > multiple TCP connections from the same host, to the same > > server (such as web > > browsing). For this case, you will for all but the first flow > > get an exact match > > for at least one of the addresses (most often both). If you > > expect a lot of > > temporally close connections like this, then your savings > > will be a lot smaller. > > > > Note: We _could_ also take into account that you're using one > > extra bit of > > discriminator per address (i.e. 2 bits per packet per IP > > header). This will > > have a negative impact on compression if we have a very high > > percentage of exact > > matches and very seldom have partial matches. > > > > So my question would be: How many separate TCP connections do > > we expect the > > average user to open up in a short timespan? 1, 10, 100? > > When I have an _idea_ of that number, I will be able to say > > if your proposal > > makes sense technically. Right now, I can't really say. > > >=20 > If you are asking TCP connection between one user and one=20 > server, then the answer is 1 with HTTP 1.1. >=20 > > > > On the IPR issue, I would not like us to add IPR:ed solutions > > unless it is a > > really large gain, but let's wait and see what your IPR > > people say before we > > take that discussion further. > > > > Best regards, > > Kristofer Sandlund, Effnet AB > > > > Yousuf.Saifullah@nokia.com wrote: > > > Hi Lars-Erik, > > > > > > Thank you for your reply. > > > > > > > > >>This is not true, and answers so far have been rather > > >>skeptical to the idea, both because of the IPR and for > > >>technical reasons. > > >> > > > > > > For IPR reason, I have an update please see the last para > > of this email. For technical reasons, allow me to disagree. I > > still have to see an argument that this is not a good > > technical solution. In the emails by Mark and Kristofer, the > > concern was raised without any argument that why it is not a > > good technical solution. I gave the technical > > reasons/advantages, but I didn't see any response back. I am > > repeating here again, I would appreciate if someone could > > comment on the following and tell me why we are skeptical > > about savings from IP address compression > > (draft-saifullah-rohc-ip-addr-comp-context-replication-00.txt): > > > > > > Having same prefix in IP addresses, both in IPv4 and IPv6, > > is quite common and should be exploited for more compression. > > > > > > Let's take the first objection, "a very small > > optimization". This is not a small optimization. An IPv6 > > address is composed of 16 bytes, and there is a potential of > > saving many bytes from both source and destination addresses. > > If we assume that the subnet prefix is 64 bits, then it has > > potential of saving 8 bytes from an IP address. 8 byte saving > > is not a small optimization, if we consider 40 bytes of the > > total IPv6 header, then it is 20% saving on the raw IP > > header. If we consider TCP and IP header (60 bytes) it still > > gives 13.33% saving. > > > > > > Also, I have mentioned in my reply to Mark that this case > > is quite frequent to consider, I am repeating myself here > > with one more example: > > > - 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. > > > - Some networks, e.g. cellular, have IP terminals with same > > prefix indicating their gateways for their external networks. > > > - Corporate LAN environment has hosts with same prefix. In > > fact, any gateway based network would have same prefix for > > the hosts in its subnetwork. > > > > > > > > > > > >>Probably not. RAND-terms is usually not considered sufficient > > >>if an "IPR-free" solution is required. > > >> > > > > > > I have communicated the WG concern to my IPR folks that > > RAND-terms is not sufficient. They should be giving us more > > information soon. In the mean time, I would request to the WG > > to evaluate the IP address compression proposal technically. > > If technically it is found worthy of adoptation, but not > > found "IPR-free" we can drop the idea. But, if it also > > satisfies the IPR-free concern, then why not adopt it. It > > would provide more saving.=20 > > > > > > Regards, > > > Yousuf > > > > > > _______________________________________________ > > > 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 >=20 >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 9 05:37:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21419 for ; Tue, 9 Dec 2003 05:37: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 1ATfEm-0007sw-Ca for rohc-archive@odin.ietf.org; Tue, 09 Dec 2003 05:37:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9Ab3mI030300 for rohc-archive@odin.ietf.org; Tue, 9 Dec 2003 05: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 1ATfEk-0007sY-Ff for rohc-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 05: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 FAA21408 for ; Tue, 9 Dec 2003 05:36:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATfEg-0005Gw-00 for rohc-web-archive@ietf.org; Tue, 09 Dec 2003 05:36:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATfEg-0005Gt-00 for rohc-web-archive@ietf.org; Tue, 09 Dec 2003 05:36:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATfEi-0007rs-Tx; Tue, 09 Dec 2003 05: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 1ATfDm-0007r3-Jw for rohc@optimus.ietf.org; Tue, 09 Dec 2003 05:36: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 FAA21395 for ; Tue, 9 Dec 2003 05:35:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATfDj-0005GS-00 for rohc@ietf.org; Tue, 09 Dec 2003 05:35:59 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ATfDi-0005G5-00 for rohc@ietf.org; Tue, 09 Dec 2003 05:35:58 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id hB99ZAqP005047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 9 Dec 2003 10:35:11 +0100 Message-ID: <3FD5A56D.90207@effnet.com> Date: Tue, 09 Dec 2003 11:35:25 +0100 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhigang.c.liu@nokia.com CC: Yousuf.Saifullah@nokia.com, lars-erik.jonsson@ericsson.com, mark.a.west@roke.co.uk, rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <7B5AF06E216CB74DA8A5960A3181B5B808E901@ajebe001.americas.nokia.com> In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B808E901@ajebe001.americas.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Zhigang, I took out some of your comments into this mail that I don't fully agree with you, I hope I do not mis-quote you. Zhigang> Assuming IPv6 and n multiple TCP connections, the cost = 1*n bits (for Zhigang> the src IP address) the gain = 64 bits. So the benefit/cost ratio = Zhigang> 64/n. Maybe I've misunderstood you, but don't you have to take into account the "matched-len" field from your draft as well? Also, you will have a 2*n-bit discriminator overhead, since both addresses will have 1 bit extra of discriminator even if only one of them is subject to "partial match". For a x-bit prefix match on one of the addresses, I think the gain/flow ratio should be (n is the number of multiple TCP connections as in your mail): (x - matched_len_width - n * 2) / n This I feel gives a fair comparison against the current replication scheme. With this formula and a 64-bit IPv6 prefix match on the source address (full match on dest), we get: (64 - 7 - n*2) / n = (57 - 2*n) / n Gain examples IPv6, 64 bit dst match: (HTTP 1.1) n=1 => 55 bits/replicated flow (HTTP 1.0) n=10 => 3.5 bits/replicated flow (HTTP 1.0) n=50 => -0.86 bits/replicated flow And for a 16-bit IPv4: (16 - 5 - n*2) / n = (11 - 2*n) / n Gain examples IPv4, 16 bit dst match: (HTTP 1.1) n=1 => 9 bits/flow (HTTP 1.0) n=10 => -0.9 bits/flow (HTTP 1.0) n=50 => -1.78 bits/flow So, my conclusion would have to be that there will be a large gain for HTTP 1.1 w/IPv6 (as you said), and for HTTP 1.0 and IPv6 there could be a small win or a small loss. For HTTP1.0/IPv4, there seems to be most likely to be a loss in efficiency. And (correct me if I'm wrong, HTTP is not one of my areas of expertise), most web servers today run HTTP 1.0 and IPv4, so to me it seems like this gives us a loss in the "normal case". Therefore, I'm still not convinced on the technical part. On the other hand, I agree that this seems simple enough, so it does not hurt complexity-wise to add it if you get a consensus on the technical side. Zhigang> Lastly, note that our proposal is not only aimed at TCP HC. It can be Zhigang> used as a general way to share context between packet flows within a Zhigang> subnet. This can be added to the format of the IR-CR for other profiles even if it is not in the TCP profile. The format of the IR-CR packet is specified on a profile-basis and even if we don't add it to TCP-IR-CR, there's nothing to say it cannot be used for other profiles, therefore I don't think this is an argument for adding it to the TCP profile. Regarding "suffix match" in the draft: Do you expect this to occur often? I cannot see this being something that can be used often and you might as well have a reserved pattern that could mean for example "50% prefix match", so you improve on the figures I presented above, by removing "matched-len" for this pattern. Best regards, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 9 12:07:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03835 for ; Tue, 9 Dec 2003 12:07: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 1ATlKD-0006m9-Vt for rohc-archive@odin.ietf.org; Tue, 09 Dec 2003 12:07:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9H75gv026036 for rohc-archive@odin.ietf.org; Tue, 9 Dec 2003 12:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATlKC-0006lr-VS for rohc-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 12:07:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03815 for ; Tue, 9 Dec 2003 12:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATlKB-0003LB-00 for rohc-web-archive@ietf.org; Tue, 09 Dec 2003 12:07:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATlKB-0003L7-00 for rohc-web-archive@ietf.org; Tue, 09 Dec 2003 12:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATlK9-0006kT-9h; Tue, 09 Dec 2003 12:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATlJX-0006je-BZ for rohc@optimus.ietf.org; Tue, 09 Dec 2003 12:06: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 MAA03798 for ; Tue, 9 Dec 2003 12:06:06 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATlJV-0003KX-00 for rohc@ietf.org; Tue, 09 Dec 2003 12:06:21 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATlJV-0003KT-00 for rohc@ietf.org; Tue, 09 Dec 2003 12:06:21 -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 hB9H6JR25293 for ; Tue, 9 Dec 2003 19:06:19 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Dec 2003 19:06:19 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 9 Dec 2003 11:06:17 -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: Tue, 9 Dec 2003 11:06:17 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398934@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO+QERowEdWO/j2QuClceyRktT6oQALlVIQ To: , Cc: , , X-OriginalArrivalTime: 09 Dec 2003 17:06:17.0703 (UTC) FILETIME=[C29D8F70:01C3BE76] 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 Kristofer, Thank you for your detailed analysis. Please read my comments below.=20 Regards, Yousuf > -----Original Message----- > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: Tuesday, December 09, 2003 4:35 AM > To: Liu Zhigang.C (NRC/Dallas) > Cc: Saifullah Yousuf (NRC/Dallas); lars-erik.jonsson@ericsson.com; > mark.a.west@roke.co.uk; rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Zhigang, >=20 > I took out some of your comments into this mail that I don't=20 > fully agree with=20 > you, I hope I do not mis-quote you. >=20 > Zhigang> Assuming IPv6 and n multiple TCP connections, the=20 > cost =3D 1*n bits (for > Zhigang> the src IP address) the gain =3D 64 bits. So the=20 > benefit/cost ratio =3D > Zhigang> 64/n. >=20 > Maybe I've misunderstood you, but don't you have to take into=20 > account the=20 > "matched-len" field from your draft as well? Also, you will=20 > have a 2*n-bit=20 > discriminator overhead, since both addresses will have 1 bit extra of=20 > discriminator even if only one of them is subject to "partial match". > For a x-bit prefix match on one of the addresses, I think the=20 > gain/flow ratio=20 > should be (n is the number of multiple TCP connections as in=20 > your mail): >=20 > (x - matched_len_width - n * 2) / n You are right the matched_len_width should be considered.=20 We are totally ignoring another dimension of multiple hosts. In your = equations we are only comparing n flows between 1 host and 1 server. If = we have m multiple hosts in the system with compressible IP addresses. = The saving will be 55*m bits for HTTP 1.1./IPv6. The theoretical value = of m could be 2^64, but we can reasonably pick a value in multiples of = tens of thousands. Let's say if we pick, 10,000. This would give a = saving of 550,000 bits. We are also ignoring the spare bits available due to byte alignment. If = we have 2 spare bits in the structure, then this n*2 will not be in the = equation. The equation will be (x - matched_len_width)/n Now let's see where we can get these 2 spare bits. I see in rohc-tcp-05 = that replicate_format_0 is defined for IPv4 only and discriminator has 4 = bits. Although, only one value is defined. If this is to fill up the = rest of the available bits, then we can easily borrow 2 bits from there. = Could anyone tell why do we have 4 bits of discriminator and one value? For IPv6, I'll comment when I see the structure as it is not present in = the rohc-tcp-05 draft. I can guess that the spare bits will be available = in that structure. IPv6 has fewer fields for discriminator and flags = compared to IPv4. =20 >=20 > This I feel gives a fair comparison against the current=20 > replication scheme. >=20 > With this formula and a 64-bit IPv6 prefix match on the=20 > source address (full=20 > match on dest), we get: >=20 > (64 - 7 - n*2) / n =3D (57 - 2*n) / n >=20 > Gain examples IPv6, 64 bit dst match: > (HTTP 1.1) n=3D1 =3D> 55 bits/replicated flow > (HTTP 1.0) n=3D10 =3D> 3.5 bits/replicated flow > (HTTP 1.0) n=3D50 =3D> -0.86 bits/replicated flow >=20 If we use two spare bits, all of the above values will be the same = irrespective of HTTP version, i.e. 55*m bits over multiple hosts and 55 = bits/replicated flow for 1 host. Similarly, for IPv4 it will all be 15*m = bits.=20 One other point, I think that n=3D50 is totally unrealistic. I would = also question n=3D10. I only have HTTP 1.1 available in my browsers, so = I won't be able to verify what should be a realistic n for HTTP 1.0.=20 I would also suggest to evaluate the cost and gain for the TCP port #s = and use bits with maximum gain. Since, we are still discussing rohc-tcp = draft. TCP port #s are also using 2*n bits more for indicating port # = compression. If we use the same formula for the TCP port #s, which has 2 = bits for src and dest port discriminator. The 8 bit source and 8 bit = destination port matches results into the following formula, with the = same analysis as yours: (16 - n*2) / n Gain examples for the port #s: (HTTP 1.1) n=3D1 =3D> 14 bits/replicated flow (HTTP 1.0) n=3D10 =3D> -0.4 bits/replicated flow (HTTP 1.0) n=3D50 =3D> -1.68 bits/replicated flow The above clearly shows that the overall IP address gain is better with = the 2 bits cost compared with the TCP port #s. I would rather have 2 = bits discriminator for the IP addresses then the TCP port #s. Please = also consider this point.=20 > And for a 16-bit IPv4: >=20 > (16 - 5 - n*2) / n =3D (11 - 2*n) / n >=20 > Gain examples IPv4, 16 bit dst match: > (HTTP 1.1) n=3D1 =3D> 9 bits/flow > (HTTP 1.0) n=3D10 =3D> -0.9 bits/flow > (HTTP 1.0) n=3D50 =3D> -1.78 bits/flow >=20 > So, my conclusion would have to be that there will be a large=20 > gain for HTTP 1.1=20 > w/IPv6 (as you said), and for HTTP 1.0 and IPv6 there could=20 > be a small win or a=20 > small loss. For HTTP1.0/IPv4, there seems to be most likely=20 > to be a loss in=20 > efficiency. > And (correct me if I'm wrong, HTTP is not one of my areas of=20 > expertise), most=20 > web servers today run HTTP 1.0 and IPv4, so to me it seems=20 > like this gives us a=20 > loss in the "normal case". Therefore, I'm still not convinced=20 > on the technical=20 > part. I would also not claim as an expert on HTTP implementation :) I would = say that HTTP 1.1 and IPv4 are more popular. It still shows gains with = your equations, and all cases show gain with the availability of 2 bits = from either spare or wise use. =20 > On the other hand, I agree that this seems simple enough, so=20 > it does not hurt=20 > complexity-wise to add it if you get a consensus on the=20 > technical side. >=20 > Zhigang> Lastly, note that our proposal is not only aimed at=20 > TCP HC. It can be > Zhigang> used as a general way to share context between=20 > packet flows within a > Zhigang> subnet. >=20 > This can be added to the format of the IR-CR for other=20 > profiles even if it is=20 > not in the TCP profile. The format of the IR-CR packet is=20 > specified on a=20 > profile-basis and even if we don't add it to TCP-IR-CR,=20 > there's nothing to say=20 > it cannot be used for other profiles, therefore I don't think=20 > this is an=20 > argument for adding it to the TCP profile. >=20 >=20 > Regarding "suffix match" in the draft: Do you expect this to=20 > occur often? I=20 > cannot see this being something that can be used often and=20 > you might as well=20 > have a reserved pattern that could mean for example "50%=20 > prefix match", so you=20 > improve on the figures I presented above, by removing=20 > "matched-len" for this=20 > pattern. > This is a good suggestion. I will think more about it. =20 > Best regards, > Kristofer Sandlund, Effnet AB >=20 >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 9 12:18:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04073 for ; Tue, 9 Dec 2003 12:18: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 1ATlUt-0007Hd-G5 for rohc-archive@odin.ietf.org; Tue, 09 Dec 2003 12:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9HI7ET027991 for rohc-archive@odin.ietf.org; Tue, 9 Dec 2003 12:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATlUt-0007HO-9C for rohc-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 12:18: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 MAA04069 for ; Tue, 9 Dec 2003 12:17:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATlUn-0003TQ-00 for rohc-web-archive@ietf.org; Tue, 09 Dec 2003 12:18:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATlUn-0003TN-00 for rohc-web-archive@ietf.org; Tue, 09 Dec 2003 12:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATlUn-0007H4-Dt; Tue, 09 Dec 2003 12:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATlU6-0007Gb-Vf for rohc@optimus.ietf.org; Tue, 09 Dec 2003 12:17:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04059 for ; Tue, 9 Dec 2003 12:17:01 -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 1ATlU5-0003TE-00 for rohc@ietf.org; Tue, 09 Dec 2003 12:17:17 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATlU4-0003TB-00 for rohc@ietf.org; Tue, 09 Dec 2003 12:17:16 -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 hB9HHGR07172 for ; Tue, 9 Dec 2003 19:17:16 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Dec 2003 19:17:15 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 9 Dec 2003 11:16:56 -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] IP Address Compression for Context Replication X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 9 Dec 2003 12:16:55 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E90B@ajebe001.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO+QESTM3iG6z0PSEarroJ9sYmm5AALY++A To: Cc: , , , X-OriginalArrivalTime: 09 Dec 2003 17:16:56.0926 (UTC) FILETIME=[3F9F3FE0:01C3BE78] 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 Kristofer, > Maybe I've misunderstood you, but don't you have to take into=20 > account the "matched-len" field from your draft as well?=20 You're right. I didn't mention it for two reasons: - the matched-len is very small compared to the prefix anyway. - the size of matched-len depends on encoding. If it is a concern, matched-len can be encoded more efficiently with less bits, e.g. use 1 bit to encode the most common case, etc. (basically, the similar idea you mentioned below for the suffix-match.) > Also, you will have a 2*n-bit=20 > discriminator overhead, since both addresses will have 1 bit extra of=20 > discriminator even if only one of them is subject to "partial match". > For a x-bit prefix match on one of the addresses, I think the=20 > gain/flow ratio should be (n is the number of multiple TCP = connections=20 > as in your mail): >=20 > (x - matched_len_width - n * 2) / n It seems you assumed only one of the address fields can be compressed? I'm not sure that's always true. But I won't spend time on it now. For the sake of argument, let's assume above n*2 term is correct. > With this formula and a 64-bit IPv6 prefix match on the=20 > source address (full match on dest), we get: >=20 > (64 - 7 - n*2) / n =3D (57 - 2*n) / n Two points:=20 - X (i.e. prefix match) could be much larger than 64 bits - matched_len_width can be less (see above). Using your own assumption of x=3D64, matched_len_width can be just 1 bit. But this is just some fine points compared to my next comment. > Gain examples IPv6, 64 bit dst match: > (HTTP 1.1) n=3D1 =3D> 55 bits/replicated flow > (HTTP 1.0) n=3D10 =3D> 3.5 bits/replicated flow > (HTTP 1.0) n=3D50 =3D> -0.86 bits/replicated flow First, I don't think n=3D50 (i.e. 50 simultaneous TCP connections) is realistic.=20 Second, the whole purpose or usefulness of TCP/IP HC is to reduce=20 header overhead. Then, why would a client open many TCP connections=20 to the same server and thus introduce extra header overhead/context,=20 instead of using one persistant connection? It would look to me like=20 creating problems and then solving it. It doen't make sense to me. > And for a 16-bit IPv4: >=20 > (16 - 5 - n*2) / n =3D (11 - 2*n) / n >=20 > Gain examples IPv4, 16 bit dst match: > (HTTP 1.1) n=3D1 =3D> 9 bits/flow > (HTTP 1.0) n=3D10 =3D> -0.9 bits/flow > (HTTP 1.0) n=3D50 =3D> -1.78 bits/flow Same points as for IPv6: X can be larger (e.g. 24 bits) and=20 matched_len_width can be smaller (e.g. 1 bits). So it would be (24 - 1 - 2*n) =3D (23 - 2*n) / n. See above for comments on n. > So, my conclusion would have to be that there will be a large=20 > gain for HTTP 1.1 w/IPv6 (as you said), and for HTTP 1.0 and=20 > IPv6 there could be a small win or a small loss.=20 > For HTTP1.0/IPv4, there seems to be most likely to be a loss in=20 > efficiency. I have to disagree. See above. > And (correct me if I'm wrong, HTTP is not one of my areas of=20 > expertise), most web servers today run HTTP 1.0 and IPv4, so=20 > to me it seems like this gives us a loss in the "normal case".=20 > Therefore, I'm still not convinced on the technical part. I don't know what is the current distribution between HTTP 1.0 and 1.1. But based on my knowledge, HTTP 1.1 used more and more to optimize performance. And for the simple reasons I gave above,=20 it doesn't make sense to me to implement TCP/IP HC without=20 eliminating the root of problems: too many TCP connections=20 incurred by HTTP 1.0. As to IPv6 vs v4, my guess is that IPv4 will stay for sometime.=20 But IPv6 will pick up, at least that is what I heard here in=20 IETF and some other standardization orgonaizations. Regardless of what is current situaiton, a viable TCP/IP HC protocol should have a good handle of IPv6. As to IPv4, IP address compression=20 still brings benifigs, though small. > On the other hand, I agree that this seems simple enough, so=20 > it does not hurt complexity-wise to add it if you get a=20 > consensus on the technical side. Good. > Zhigang> Lastly, note that our proposal is not only aimed at=20 > TCP HC. It can be > Zhigang> used as a general way to share context between=20 > packet flows within a > Zhigang> subnet. >=20 > This can be added to the format of the IR-CR for other=20 > profiles even if it is=20 > not in the TCP profile. The format of the IR-CR packet is=20 > specified on a=20 > profile-basis and even if we don't add it to TCP-IR-CR,=20 > there's nothing to say=20 > it cannot be used for other profiles, therefore I don't think=20 > this is an=20 > argument for adding it to the TCP profile. Agree, that alone is not an argument for adding it to TCP profile.=20 > Regarding "suffix match" in the draft: Do you expect this to=20 > occur often? I cannot see this being something that can be used often = and=20 > you might as well have a reserved pattern that could mean for example = "50%=20 > prefix match", so you improve on the figures I presented above, by = removing=20 > "matched-len" for this pattern. I honestly don't know how often "suffix match" will occur, but think it's something useful to plan in protocol.=20 And yes, there are more efficient encoding like you mentioned above.=20 We do have some detailed ideas but didn't include the them in our=20 first draft (though it is too early). It's good that you bring up=20 this issues. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 10 03:04:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03632 for ; Wed, 10 Dec 2003 03:04:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzKH-0007xT-R8 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 03:04:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA845lE030588 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 03:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzKH-0007xH-Dt for rohc-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 03:04: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 DAA03624 for ; Wed, 10 Dec 2003 03:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATzKD-0005Nv-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 03:04:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATzKD-0005Ns-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 03:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzKE-0007x1-DB; Wed, 10 Dec 2003 03:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzJj-0007w0-Mp for rohc@optimus.ietf.org; Wed, 10 Dec 2003 03:03: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 DAA03610 for ; Wed, 10 Dec 2003 03:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATzJf-0005NN-00 for rohc@ietf.org; Wed, 10 Dec 2003 03:03:27 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ATzJe-0005Mx-00 for rohc@ietf.org; Wed, 10 Dec 2003 03:03:27 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id hBA72cqP008946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Dec 2003 08:02:41 +0100 Message-ID: <3FD6D32B.10009@effnet.com> Date: Wed, 10 Dec 2003 09:02:51 +0100 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhigang.c.liu@nokia.com CC: Yousuf.Saifullah@nokia.com, lars-erik.jonsson@ericsson.com, mark.a.west@roke.co.uk, rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <7B5AF06E216CB74DA8A5960A3181B5B808E90B@ajebe001.americas.nokia.com> In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B808E90B@ajebe001.americas.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Zhigang & Yousuf, Zhigang: You make a number of valid points. I still belive that the largest part of the flows can be replicated by exact match, thus making n>1 for the common case. Regaring n=50 being unreasonable, I did a quick test. Using the "trafshow" (http://soft.risp.ru/trafshow/index_en.shtml) program that shows open connections in realtime, I opended my web browser (Opera 7.21) to one of Sweden's most popular web sites, www.aftonbladet.se. What I got was something like 70 connections within a few seconds, even though I filtered to show only that specific host. Maybe not the best example (it could be an extreme case), but it shows that it definitely is not unrealistic for a very much used web page. But maybe there's no point in discussing the finer points of HTTP, we can proably both make examples showing things one way or the other. Since it is just the three of us discussing this right now, I'd like to see what the others think before we continue this. If it is to be added, I'd prefer if you had a more simple encoding (as you mention that you have prepared) that could only match a few of the most useful cases. I dislike this "variable number of bits" encoding. If you could have an enconding that always is a multiple of octets, then I'd be much more happy. We've tried to have as much byte-alignment as possible in the TCP packet formats, so it would help if this also was that. Yousuf>I would also suggest to evaluate the cost and gain for the TCP port #s Yousuf>and use bits with maximum gain. Since, we are still discussing rohc-tcp Yousuf>draft. TCP port #s are also using 2*n bits more for indicating port # Yousuf>compression. If we use the same formula for the TCP port #s, which has 2 Yousuf>bits for src and dest port discriminator. The 8 bit source and 8 bit Yousuf>destination port matches results into the following formula, with the Yousuf>same analysis as yours Hmm.. I'm not sure my analysis really works on TCP ports. Here, we are likely to see the ephemeral port be prefix matched almost all the time, since the normal allocation scheme will be more or less sequential. Even if I open 50 "near-simultaneous" connections, I won't be getting any exact matches on the port numbers. Due to this behavior, TCP ports "partial matching" makes more sense to me than addresses. BR, Kristofer Sandlund, Effnet AB zhigang.c.liu@nokia.com wrote: > Hi Kristofer, > > >>Maybe I've misunderstood you, but don't you have to take into >>account the "matched-len" field from your draft as well? > > > You're right. I didn't mention it for two reasons: > - the matched-len is very small compared to the prefix anyway. > - the size of matched-len depends on encoding. If it is > a concern, matched-len can be encoded more efficiently with > less bits, e.g. use 1 bit to encode the most common case, etc. > (basically, the similar idea you mentioned below for the suffix-match.) > > >>Also, you will have a 2*n-bit >>discriminator overhead, since both addresses will have 1 bit extra of >>discriminator even if only one of them is subject to "partial match". >>For a x-bit prefix match on one of the addresses, I think the >>gain/flow ratio should be (n is the number of multiple TCP connections >>as in your mail): >> >>(x - matched_len_width - n * 2) / n > > > It seems you assumed only one of the address fields can be compressed? > I'm not sure that's always true. But I won't spend time on it now. For > the sake of argument, let's assume above n*2 term is correct. > > >>With this formula and a 64-bit IPv6 prefix match on the >>source address (full match on dest), we get: >> >> (64 - 7 - n*2) / n = (57 - 2*n) / n > > > Two points: > - X (i.e. prefix match) could be much larger than 64 bits > - matched_len_width can be less (see above). Using your > own assumption of x=64, matched_len_width can be just 1 bit. > > But this is just some fine points compared to my next comment. > > >>Gain examples IPv6, 64 bit dst match: >>(HTTP 1.1) n=1 => 55 bits/replicated flow >>(HTTP 1.0) n=10 => 3.5 bits/replicated flow >>(HTTP 1.0) n=50 => -0.86 bits/replicated flow > > > First, I don't think n=50 (i.e. 50 simultaneous TCP connections) is > realistic. > > Second, the whole purpose or usefulness of TCP/IP HC is to reduce > header overhead. Then, why would a client open many TCP connections > to the same server and thus introduce extra header overhead/context, > instead of using one persistant connection? It would look to me like > creating problems and then solving it. It doen't make sense to me. > > >>And for a 16-bit IPv4: >> >> (16 - 5 - n*2) / n = (11 - 2*n) / n >> >>Gain examples IPv4, 16 bit dst match: >>(HTTP 1.1) n=1 => 9 bits/flow >>(HTTP 1.0) n=10 => -0.9 bits/flow >>(HTTP 1.0) n=50 => -1.78 bits/flow > > > Same points as for IPv6: X can be larger (e.g. 24 bits) and > matched_len_width can be smaller (e.g. 1 bits). So it would > be (24 - 1 - 2*n) = (23 - 2*n) / n. > > See above for comments on n. > > >>So, my conclusion would have to be that there will be a large >>gain for HTTP 1.1 w/IPv6 (as you said), and for HTTP 1.0 and >>IPv6 there could be a small win or a small loss. >>For HTTP1.0/IPv4, there seems to be most likely to be a loss in >>efficiency. > > > I have to disagree. See above. > > >>And (correct me if I'm wrong, HTTP is not one of my areas of >>expertise), most web servers today run HTTP 1.0 and IPv4, so >>to me it seems like this gives us a loss in the "normal case". >>Therefore, I'm still not convinced on the technical part. > > > I don't know what is the current distribution between HTTP 1.0 > and 1.1. But based on my knowledge, HTTP 1.1 used more and more > to optimize performance. And for the simple reasons I gave above, > it doesn't make sense to me to implement TCP/IP HC without > eliminating the root of problems: too many TCP connections > incurred by HTTP 1.0. > > As to IPv6 vs v4, my guess is that IPv4 will stay for sometime. > But IPv6 will pick up, at least that is what I heard here in > IETF and some other standardization orgonaizations. Regardless > of what is current situaiton, a viable TCP/IP HC protocol should > have a good handle of IPv6. As to IPv4, IP address compression > still brings benifigs, though small. > > >>On the other hand, I agree that this seems simple enough, so >>it does not hurt complexity-wise to add it if you get a >>consensus on the technical side. > > > Good. > > >>Zhigang> Lastly, note that our proposal is not only aimed at >>TCP HC. It can be >>Zhigang> used as a general way to share context between >>packet flows within a >>Zhigang> subnet. >> >>This can be added to the format of the IR-CR for other >>profiles even if it is >>not in the TCP profile. The format of the IR-CR packet is >>specified on a >>profile-basis and even if we don't add it to TCP-IR-CR, >>there's nothing to say >>it cannot be used for other profiles, therefore I don't think >>this is an >>argument for adding it to the TCP profile. > > > Agree, that alone is not an argument for adding it to TCP profile. > > >>Regarding "suffix match" in the draft: Do you expect this to >>occur often? I cannot see this being something that can be used often and >>you might as well have a reserved pattern that could mean for example "50% >>prefix match", so you improve on the figures I presented above, by removing >>"matched-len" for this pattern. > > > I honestly don't know how often "suffix match" will occur, but think > it's something useful to plan in protocol. > > And yes, there are more efficient encoding like you mentioned above. > We do have some detailed ideas but didn't include the them in our > first draft (though it is too early). It's good that you bring up > this issues. > > BR, > Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 10 04:51:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05613 for ; Wed, 10 Dec 2003 04:51:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU0zv-0003Wn-Ol for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 04:51:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA9pBX8013555 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 04:51:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU0zq-0003WV-0w for rohc-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 04:51: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 EAA05585 for ; Wed, 10 Dec 2003 04:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU0zm-0006R2-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 04:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU0zl-0006Qz-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 04:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU0zn-0003W5-7w; Wed, 10 Dec 2003 04: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 1AU0z4-0003Uy-Io for rohc@optimus.ietf.org; Wed, 10 Dec 2003 04:50:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05562 for ; Wed, 10 Dec 2003 04:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU0z1-0006QN-00 for rohc@ietf.org; Wed, 10 Dec 2003 04:50:15 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AU0z0-0006QK-00 for rohc@ietf.org; Wed, 10 Dec 2003 04:50:14 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBA9oFSs026131 for ; Wed, 10 Dec 2003 10:50:15 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Dec 2003 10:50:15 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Wed, 10 Dec 2003 10:49:48 +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: , Kristofer, Zhigang, and others, I think Kristofer makes some very important points here... > Zhigang: > You make a number of valid points. I still believe that the > largest part of the > flows can be replicated by exact match, thus making n>1 for > the common case. Yes, for the scenarios I can see where there would be any inter-flow correlation between IP-addresses, most cases should be with an exact match (see below). > Regaring n=50 being unreasonable, I did a quick test. > Using the "trafshow" (http://soft.risp.ru/trafshow/index_en.shtml) > program that shows open connections in realtime, I opended > my web browser (Opera 7.21) to one of Sweden's most popular web > sites, www.aftonbladet.se. What I got was something > like 70 connections within a few seconds, even though I > filtered to show only that specific host. I think this is an example of the cases we have been aiming at when developing context replication for the TCP profile. > Yousuf>I would also suggest to evaluate the cost and gain for > the TCP port #s and use bits with maximum gain. Since, we > are still discussing rohc-tcp draft. TCP port #s are also > using 2*n bits more for indicating port # compression. If we > use the same formula for the TCP port #s, which has 2 > bits for src and dest port discriminator. The 8 bit source > and 8 bit destination port matches results into the following > formula, with the same analysis as yours > > Hmm.. I'm not sure my analysis really works on TCP ports. > Here, we are likely to see the ephemeral port be prefix > matched almost all the time, since the normal allocation > scheme will be more or less sequential. Even if I open 50 > "near-simultaneous" connections, I won't be getting any exact > matches on the port numbers. Due to this behavior, TCP > ports "partial matching" makes more sense to me than addresses. This is another important key-point. I have been convinced that it might happen rather often that many flows passing through the same compressor/decompressor have the same source and/or destination IP address. The case Kristofer exemplified above is the typical example, and this would realistically happen over a "compressed link", as compression is usually applied on access links, where at least one IP address will be the same for most connections. Having compression for port numbers also makes sense as ports are usually sequentially assigned and will thus "be close" to each other for all these parallel connections. Although I can see cases when also IP addresses will "be close", I do not think these cases are as obvious and common. Further, for the cases I can see, I do not think compression is as important, as these will not at all be comparable (in #'s) to the example with HTTP multiple connections (as exemplified above). /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 10 13:49:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09200 for ; Wed, 10 Dec 2003 13:49:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9OR-00076Z-Uf for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 13:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAIn3n8027307 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 13:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9OR-00076M-Pv for rohc-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 13:49: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 NAA09161 for ; Wed, 10 Dec 2003 13:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9OP-0005bD-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 13:49:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU9OP-0005b9-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 13: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 1AU9OP-00075Z-4d; Wed, 10 Dec 2003 13: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 1AU8zZ-0005qG-4Z for rohc@optimus.ietf.org; Wed, 10 Dec 2003 13:23:21 -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 NAA07865 for ; Wed, 10 Dec 2003 13:14:35 -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 1AU8k0-0004wB-00 for rohc@ietf.org; Wed, 10 Dec 2003 13:07:16 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AU8jz-0004w8-00 for rohc@ietf.org; Wed, 10 Dec 2003 13:07:15 -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 hBAI7EQ16966 for ; Wed, 10 Dec 2003 20:07:14 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 20:07:13 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 12:07:06 -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] IP Address Compression for Context Replication X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 10 Dec 2003 13:07:04 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E910@ajebe001.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO+9FAgAsACp9p+T+WatRitEADoSQAS0YPQ To: Cc: , , , X-OriginalArrivalTime: 10 Dec 2003 18:07:06.0640 (UTC) FILETIME=[6BF6E900:01C3BF48] 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 Kristofer, As you said, n =3D 70 could be an extreme case. There are also the cases where n=3D1 or close to 1. One simple example: HTTP 1.1 origin server,=20 regardless the content of the web sites. I also tested www.aftonbladet.se using IE as browser and Ethereal as=20 packet sniffer. I saw one TCP connection. And I expected this. That=20 is because we have a HTTP proxy server for the subnet in my office.=20 This brings another simple example: HTTP 1.1 proxy server, regardless if the origin server supports HTTP 1.1. A proxy server is quite typical=20 configuration for a subnet. (Back to your test result, I guess it could be caused by the following reasons. You should know better than me. - you don't have an HTTP 1.1 proxy server - your browser does not supports 1.1 - the origin server at www.aftonbladet.se does not support HTTP 1.1) Note that theses are not fine points of HTTP. (I'm risking repeating myself since unfortunately I don't see your reply on those points.) They are important considering what is the real purpose/usefulness of = TCP context replication, or the entire TCP HC profile. If we want to reduce "bit-over-the-air" and the associated delay, which is the goal of TCP HC, persistent connection in HTTP 1.1 is probably the first thing we should do (if it hasn't been done). This has been well studied in many papers/experiments. So, n=3D1 or n close to 1 will be common cases, if it hasn't been so. Do you agree? RE encoding, that's something we can refine later after we agree IP address compression is part of TCP profile. As a matter of fact, I don't even see IPv6 format in current TCP draft. We're already one step ahead and need to have the overall picture to proceed. BR, Zhigang > -----Original Message----- > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: December 10, 2003 02:03 AM > To: Liu Zhigang.C (NRC/Dallas) > Cc: Saifullah Yousuf (NRC/Dallas); lars-erik.jonsson@ericsson.com; > mark.a.west@roke.co.uk; rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Zhigang & Yousuf, >=20 > Zhigang: > You make a number of valid points. I still belive that the=20 > largest part of the=20 > flows can be replicated by exact match, thus making n>1 for=20 > the common case. >=20 > Regaring n=3D50 being unreasonable, I did a quick test. > Using the "trafshow"=20 > (http://soft.risp.ru/trafshow/index_en.shtml) program that=20 > shows open connections in realtime, I opended my web browser=20 > (Opera 7.21) to one=20 > of Sweden's most popular web sites, www.aftonbladet.se. What=20 > I got was something=20 > like 70 connections within a few seconds, even though I=20 > filtered to show only=20 > that specific host. Maybe not the best example (it could be=20 > an extreme case),=20 > but it shows that it definitely is not unrealistic for a very=20 > much used web page. > But maybe there's no point in discussing the finer points of=20 > HTTP, we can=20 > proably both make examples showing things one way or the=20 > other. Since it is just=20 > the three of us discussing this right now, I'd like to see=20 > what the others think=20 > before we continue this. >=20 > If it is to be added, I'd prefer if you had a more simple=20 > encoding (as you=20 > mention that you have prepared) that could only match a few=20 > of the most useful=20 > cases. I dislike this "variable number of bits" encoding. If=20 > you could have an=20 > enconding that always is a multiple of octets, then I'd be=20 > much more happy.=20 > We've tried to have as much byte-alignment as possible in the=20 > TCP packet=20 > formats, so it would help if this also was that. >=20 > Yousuf>I would also suggest to evaluate the cost and gain for=20 > the TCP port #s > Yousuf>and use bits with maximum gain. Since, we are still=20 > discussing rohc-tcp > Yousuf>draft. TCP port #s are also using 2*n bits more for=20 > indicating port # > Yousuf>compression. If we use the same formula for the TCP=20 > port #s, which has 2 > Yousuf>bits for src and dest port discriminator. The 8 bit=20 > source and 8 bit > Yousuf>destination port matches results into the following=20 > formula, with the > Yousuf>same analysis as yours >=20 > Hmm.. I'm not sure my analysis really works on TCP ports.=20 > Here, we are likely to=20 > see the ephemeral port be prefix matched almost all the time,=20 > since the normal=20 > allocation scheme will be more or less sequential. Even if I open 50=20 > "near-simultaneous" connections, I won't be getting any exact=20 > matches on the=20 > port numbers. Due to this behavior, TCP ports "partial=20 > matching" makes more=20 > sense to me than addresses. >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 >=20 > zhigang.c.liu@nokia.com wrote: > > Hi Kristofer, > >=20 > >=20 > >>Maybe I've misunderstood you, but don't you have to take into=20 > >>account the "matched-len" field from your draft as well?=20 > >=20 > >=20 > > You're right. I didn't mention it for two reasons: > > - the matched-len is very small compared to the prefix anyway. > > - the size of matched-len depends on encoding. If it is > > a concern, matched-len can be encoded more efficiently with > > less bits, e.g. use 1 bit to encode the most common case, etc. > > (basically, the similar idea you mentioned below for the=20 > suffix-match.) > >=20 > >=20 > >>Also, you will have a 2*n-bit=20 > >>discriminator overhead, since both addresses will have 1=20 > bit extra of=20 > >>discriminator even if only one of them is subject to=20 > "partial match". > >>For a x-bit prefix match on one of the addresses, I think the=20 > >>gain/flow ratio should be (n is the number of multiple TCP=20 > connections=20 > >>as in your mail): > >> > >>(x - matched_len_width - n * 2) / n > >=20 > >=20 > > It seems you assumed only one of the address fields can be=20 > compressed? > > I'm not sure that's always true. But I won't spend time on=20 > it now. For > > the sake of argument, let's assume above n*2 term is correct. > >=20 > >=20 > >>With this formula and a 64-bit IPv6 prefix match on the=20 > >>source address (full match on dest), we get: > >> > >> (64 - 7 - n*2) / n =3D (57 - 2*n) / n > >=20 > >=20 > > Two points:=20 > > - X (i.e. prefix match) could be much larger than 64 bits > > - matched_len_width can be less (see above). Using your > > own assumption of x=3D64, matched_len_width can be just 1 bit. > >=20 > > But this is just some fine points compared to my next comment. > >=20 > >=20 > >>Gain examples IPv6, 64 bit dst match: > >>(HTTP 1.1) n=3D1 =3D> 55 bits/replicated flow > >>(HTTP 1.0) n=3D10 =3D> 3.5 bits/replicated flow > >>(HTTP 1.0) n=3D50 =3D> -0.86 bits/replicated flow > >=20 > >=20 > > First, I don't think n=3D50 (i.e. 50 simultaneous TCP connections) = is > > realistic.=20 > >=20 > > Second, the whole purpose or usefulness of TCP/IP HC is to reduce=20 > > header overhead. Then, why would a client open many TCP connections=20 > > to the same server and thus introduce extra header=20 > overhead/context,=20 > > instead of using one persistant connection? It would look=20 > to me like=20 > > creating problems and then solving it. It doen't make sense to me. > >=20 > >=20 > >>And for a 16-bit IPv4: > >> > >> (16 - 5 - n*2) / n =3D (11 - 2*n) / n > >> > >>Gain examples IPv4, 16 bit dst match: > >>(HTTP 1.1) n=3D1 =3D> 9 bits/flow > >>(HTTP 1.0) n=3D10 =3D> -0.9 bits/flow > >>(HTTP 1.0) n=3D50 =3D> -1.78 bits/flow > >=20 > >=20 > > Same points as for IPv6: X can be larger (e.g. 24 bits) and=20 > > matched_len_width can be smaller (e.g. 1 bits). So it would > > be (24 - 1 - 2*n) =3D (23 - 2*n) / n. > >=20 > > See above for comments on n. > >=20 > >=20 > >>So, my conclusion would have to be that there will be a large=20 > >>gain for HTTP 1.1 w/IPv6 (as you said), and for HTTP 1.0 and=20 > >>IPv6 there could be a small win or a small loss.=20 > >>For HTTP1.0/IPv4, there seems to be most likely to be a loss in=20 > >>efficiency. > >=20 > >=20 > > I have to disagree. See above. > >=20 > >=20 > >>And (correct me if I'm wrong, HTTP is not one of my areas of=20 > >>expertise), most web servers today run HTTP 1.0 and IPv4, so=20 > >>to me it seems like this gives us a loss in the "normal case".=20 > >>Therefore, I'm still not convinced on the technical part. > >=20 > >=20 > > I don't know what is the current distribution between HTTP 1.0 > > and 1.1. But based on my knowledge, HTTP 1.1 used more and more > > to optimize performance. And for the simple reasons I gave above,=20 > > it doesn't make sense to me to implement TCP/IP HC without=20 > > eliminating the root of problems: too many TCP connections=20 > > incurred by HTTP 1.0. > >=20 > > As to IPv6 vs v4, my guess is that IPv4 will stay for sometime.=20 > > But IPv6 will pick up, at least that is what I heard here in=20 > > IETF and some other standardization orgonaizations. Regardless > > of what is current situaiton, a viable TCP/IP HC protocol should > > have a good handle of IPv6. As to IPv4, IP address compression=20 > > still brings benifigs, though small. > >=20 > >=20 > >>On the other hand, I agree that this seems simple enough, so=20 > >>it does not hurt complexity-wise to add it if you get a=20 > >>consensus on the technical side. > >=20 > >=20 > > Good. > >=20 > >=20 > >>Zhigang> Lastly, note that our proposal is not only aimed at=20 > >>TCP HC. It can be > >>Zhigang> used as a general way to share context between=20 > >>packet flows within a > >>Zhigang> subnet. > >> > >>This can be added to the format of the IR-CR for other=20 > >>profiles even if it is=20 > >>not in the TCP profile. The format of the IR-CR packet is=20 > >>specified on a=20 > >>profile-basis and even if we don't add it to TCP-IR-CR,=20 > >>there's nothing to say=20 > >>it cannot be used for other profiles, therefore I don't think=20 > >>this is an=20 > >>argument for adding it to the TCP profile. > >=20 > >=20 > > Agree, that alone is not an argument for adding it to TCP profile.=20 > >=20 > >=20 > >>Regarding "suffix match" in the draft: Do you expect this to=20 > >>occur often? I cannot see this being something that can be=20 > used often and=20 > >>you might as well have a reserved pattern that could mean=20 > for example "50%=20 > >>prefix match", so you improve on the figures I presented=20 > above, by removing=20 > >>"matched-len" for this pattern. > >=20 > >=20 > > I honestly don't know how often "suffix match" will occur, but think > > it's something useful to plan in protocol.=20 > >=20 > > And yes, there are more efficient encoding like you=20 > mentioned above.=20 > > We do have some detailed ideas but didn't include the them in our=20 > > first draft (though it is too early). It's good that you bring up=20 > > this issues. > >=20 > > BR, > > Zhigang >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 10 16:47:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20216 for ; Wed, 10 Dec 2003 16:47:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCAg-0000Z9-0V for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 16:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBALl1MF002169 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 16: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 1AUCAf-0000Yu-Sc for rohc-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 16:47: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 QAA20199 for ; Wed, 10 Dec 2003 16:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUCAd-0002q9-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 16:46:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUCAc-0002q6-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 16: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 1AUCAe-0000Ye-OY; Wed, 10 Dec 2003 16:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUC9p-0000Y1-OZ for rohc@optimus.ietf.org; Wed, 10 Dec 2003 16:46: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 QAA20080 for ; Wed, 10 Dec 2003 16:46:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUC9n-0002pQ-00 for rohc@ietf.org; Wed, 10 Dec 2003 16:46:07 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AUC9m-0002n1-00 for rohc@ietf.org; Wed, 10 Dec 2003 16:46:06 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBALjaHQ013151; Wed, 10 Dec 2003 15:45:36 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 15:45:37 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866C7@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Surtees, Abigail'" , "'rohc@ietf.org'" Subject: RE: [rohc] Sigcomp Nack Draft -01 Date: Wed, 10 Dec 2003 15:45:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] wrote: > Here are some comments on the Nack draft. > > Section 2.1 > > Last sentence: > The change in behavior for a reliable transport no longer > involves re-transmitting the message so why would you need to > be able to retrieve a plain-text version of the message? This was editorial oversight. I've removed the final sentence of this section. > Section 2.3.2 > > If the underlying TCP connection has caused SigComp to fail, > can it be trusted to transmit a NACK? In my experience, most SigComp failures are caused by failures that are independent of the underlying transport; for example, implementations erroneously referring to previously discarded state. Of course, if the transport fails altogether, then the NACK probably won't make it through either; however, transport failures are not the focus of this mechanism. > Section 2.4 > > This mechanism is a good idea. It gives a definitive way for > a compressor to find out if the other end supports the nack scheme. > > The probe idea is also possible but does have the limitations > mentioned so I don't think is worth having to the draft. The probing was included as an aside to spur discussion, since I thought that grabbing memory location 11 for advertising extensions might be controversial. > Appendix B: Changes > > Moving NACK parameters: > Isn't it impossible to have standalone feedback messages > (other than NACKs) because there is no way to determine for > which compartment the ACK is unless there is a message to go with it? > I don't think there is any problem with the message format itself. This particular change was made at Richard's suggestion... If I recall correctly, standalone feedback is possible over secured links. Presumably, compartment correlation is done on a per-connection basis, but my memory is a bit rusty on this at the moment. /a _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 10 18:13:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24861 for ; Wed, 10 Dec 2003 18:13: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 1AUDVv-0005di-HE for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 18:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAND3F0021672 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 18:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUDVv-0005dT-D1 for rohc-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 18:13: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 SAA24801 for ; Wed, 10 Dec 2003 18:12:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUDVr-0004cq-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 18:12:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUDVr-0004cn-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 18:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUDVt-0005cM-VG; Wed, 10 Dec 2003 18: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 1AUDVh-0005bz-Ej for rohc@optimus.ietf.org; Wed, 10 Dec 2003 18:12:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24778 for ; Wed, 10 Dec 2003 18:12:44 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUDVd-0004ck-00 for rohc@ietf.org; Wed, 10 Dec 2003 18:12:45 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUDVd-0004ch-00 for rohc@ietf.org; Wed, 10 Dec 2003 18:12:45 -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 hBANCjQ25138 for ; Thu, 11 Dec 2003 01:12:45 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Dec 2003 01:12:44 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 15:12:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Wed, 10 Dec 2003 17:12:42 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398937@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO+9FHONE2/4T56TYOi8nF1/Z+YxAAbaOvA To: , Cc: , , X-OriginalArrivalTime: 10 Dec 2003 23:12:43.0047 (UTC) FILETIME=[1D509370:01C3BF73] 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 Kristofer & Lars-Erik, Please find my answers in this email. My comments don't have any = indentation of ">".=20 Also, I have asked this before but I didn't get any answer. Could anyone = please tell me why discriminator in replicate_format_0 on Page 32 of = rohc-tcp-05 has 4 bits and only one value. replicate_format_0 ::=3D discriminator, % 4 = bits > -----Original Message----- > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: Wednesday, December 10, 2003 2:03 AM > To: Liu Zhigang.C (NRC/Dallas) > Cc: Saifullah Yousuf (NRC/Dallas); lars-erik.jonsson@ericsson.com; > mark.a.west@roke.co.uk; rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Zhigang & Yousuf, >=20 > Zhigang: > You make a number of valid points. I still belive that the=20 > largest part of the=20 > flows can be replicated by exact match, thus making n>1 for=20 > the common case. >=20 > Regaring n=3D50 being unreasonable, I did a quick test. > Using the "trafshow"=20 > (http://soft.risp.ru/trafshow/index_en.shtml) program that=20 > shows open connections in realtime, I opended my web browser=20 > (Opera 7.21) to one=20 > of Sweden's most popular web sites, www.aftonbladet.se. What=20 > I got was something=20 > like 70 connections within a few seconds, even though I=20 > filtered to show only=20 > that specific host. Maybe not the best example (it could be=20 > an extreme case),=20 > but it shows that it definitely is not unrealistic for a very=20 > much used web page. > But maybe there's no point in discussing the finer points of=20 > HTTP, we can=20 > proably both make examples showing things one way or the=20 > other. Since it is just=20 > the three of us discussing this right now, I'd like to see=20 > what the others think=20 > before we continue this. >=20 > If it is to be added, I'd prefer if you had a more simple=20 > encoding (as you=20 > mention that you have prepared) that could only match a few=20 > of the most useful=20 > cases. I dislike this "variable number of bits" encoding. If=20 > you could have an=20 > enconding that always is a multiple of octets, then I'd be=20 > much more happy.=20 > We've tried to have as much byte-alignment as possible in the=20 > TCP packet=20 > formats, so it would help if this also was that. >=20 Please consider the following byte-aligned structure. For IPv4: =20 Option 1: Encoding will be in bytes. 2 bits for matched-len in bytes. = Three un-matched bytes is not sent for destination. I am considering = that detination is full match most of the time. matched-len for both src = and dest can be placed together. There will still be byte alignment = problem with the matched-len fields. ip_src_addr.matched_len % 0 (No Match & Full Match) or 2 bits ip_dest_addr.matched_len % 0 (No Match & Full Match)or 2 bits ip_src_addr, % 0 (Full Match); unmatched 8, 16 or = 24 bits; 32 bits (No Match) ip_dst_addr, % 0 (Full Match); unmatched 8 or 16 = bits ; 32 bits (No Match) Option 2: 2 bits for matched-len in bytes. unmatched bits would be 6, = 14, or 22 bits. There won't be any byte alignment problem with the = matched-len. ip_src_addr.matched_len % 0 (No Match & Full Match) or 2 bits ip_src_addr, % 0 (Full Match); unmatched 6, 12, = or 22 bits ; 32 bits (No Match) ip_dest_addr.matched_len % 0 (No Match & Full Match)or 2 bits ip_dst_addr, % 0 (Full Match); unmatched 6, 12, = or 22 bits ; 32 bits (No Match) I think option 2 is better, but I would let the WG decide. For IPv6:=20 4 bits for matched-len in bytes. unmatched bytes will be 1 to 15. = matched-len for both src & dest can be placed together and this creates = a byte alignment. ip_src_addr.matched_len % 0 (No Match & Full Match) or 4 bits ip_dest_addr.matched_len % 0 (No Match & Full Match)or 4 bits ip_src_addr, % 0 (Full Match); unmatched 8, 16, = 24 ... 120 bits; 128 bits (No Match) ip_dst_addr, % 0 (Full Match); unmatched 8, 16, = 24, ... 112 bits ; 128 bits (No Match) =20 > Yousuf>I would also suggest to evaluate the cost and gain for=20 > the TCP port #s > Yousuf>and use bits with maximum gain. Since, we are still=20 > discussing rohc-tcp > Yousuf>draft. TCP port #s are also using 2*n bits more for=20 > indicating port # > Yousuf>compression. If we use the same formula for the TCP=20 > port #s, which has 2 > Yousuf>bits for src and dest port discriminator. The 8 bit=20 > source and 8 bit > Yousuf>destination port matches results into the following=20 > formula, with the > Yousuf>same analysis as yours >=20 > Hmm.. I'm not sure my analysis really works on TCP ports.=20 > Here, we are likely to=20 > see the ephemeral port be prefix matched almost all the time,=20 > since the normal=20 > allocation scheme will be more or less sequential. Even if I open 50=20 > "near-simultaneous" connections, I won't be getting any exact=20 > matches on the=20 > port numbers. Due to this behavior, TCP ports "partial=20 > matching" makes more=20 > sense to me than addresses. >=20 Also, Lars-Erik wrote: >=20 > This is another important key-point. I have been convinced that > it might happen rather often that many flows passing through > the same compressor/decompressor have the same source and/or > destination IP address. The case Kristofer exemplified above > is the typical example, and this would realistically happen > over a "compressed link", as compression is usually applied > on access links, where at least one IP address will be the > same for most connections. Having compression for port numbers > also makes sense as ports are usually sequentially assigned > and will thus "be close" to each other for all these parallel > connections.=20 >=20 > Although I can see cases when also IP addresses will "be close", > I do not think these cases are as obvious and common. Further, > for the cases I can see, I do not think compression is as > important, as these will not at all be comparable (in #'s) to > the example with HTTP multiple connections (as exemplified above).=20 >=20 The HTTP multiple connection example is already commented by Zhigang = that why it is not that frequent. I have said in my last posts that = limiting context replication to 1 host and 1 server is an unnecessary = limitation. We are totally ignoring another dimension of multiple hosts = over a "compressed link". I have given these cases before few times. = Please see the following post:=20 http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01853.ht= ml Could you please tell me why these cases are not obvious and common. I = see them occuring more than multiple TCP connections between 1 host and = 1 server. The reason is the common use of HTTP 1.1, and also proxy, = would not let multiple TCP connections to occur. I have given this number before. I am repeating it here again. If we = have m multiple hosts in the system with compressible IP addresses, then = the saving is m*(gain per flow). The saving will be 55*m bits for HTTP = 1.1./IPv6.=20 Thanks, Yousuf _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 10 19:27:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27484 for ; Wed, 10 Dec 2003 19:27:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUEfG-00085s-3N for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 19:26:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB0QkTv031106 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 19:26:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUEfF-00085d-Tx for rohc-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 19:26: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 TAA27423 for ; Wed, 10 Dec 2003 19:26:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUEfD-0005rS-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 19:26:43 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUEfC-0005rB-02 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 19:26:43 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUEag-00040W-Sk for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 19:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUEae-0007pc-LQ; Wed, 10 Dec 2003 19: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 1AUEaW-0007pI-5D for rohc@optimus.ietf.org; Wed, 10 Dec 2003 19:21:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27154 for ; Wed, 10 Dec 2003 19:21:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUEaT-0005jj-00 for rohc@ietf.org; Wed, 10 Dec 2003 19:21:49 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AUEaS-0005jV-00 for rohc@ietf.org; Wed, 10 Dec 2003 19:21:49 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBB0KFHQ013350; Wed, 10 Dec 2003 18:21:19 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 18:20:15 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866C8@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Pekka Pessi'" , rohc@ietf.org, Adam Roach Date: Wed, 10 Dec 2003 18:20:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE: Comments to draft-roach-sigcomp-nack-01 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Pekka Pessi [mailto:Pekka.Pessi@nokia.com] wrote: > > Technical issues: > > In the 2.2 last paragraph talks about destination address of > NACK: > > >>>For a connectionless transport, such as UDP, the NACK > message is sent > >>>back to the originator of the failed message at the port and IP > >>>address from which the message was sent. Note that this may or may > >>>not be the same port to which the appliation would > typically receive > >>>messages. > > I'd also like to state that the NACK should be sent from the > port and IP to which the original message was sent. This because > the sender has most probably connect()ed the sending socket in > order to catch ICMPs. I'll put text in to that effect. > This also means that the socket used to receive SIGCOMP messages > should not be bound to INADDR_ANY. Not to mention in6addr_any. I don't think this is necessarily an implication. As long as the implementation can make certain that the response is sent from the same IP address, that's all we really need. > Comment to 3.2 Reason Codes: > > The set of reason codes seems to be rather complete. However, > selecting reason code is not straightforward if the STATE-ACCESS > has zero state-length but nonzero state-begin. > INVALID_STATE_PROBE? Yes, I missed this error case. I will add it. > What about errors mentioned by RFC 3320 section 8.7 item 7 > (RETURN_WITHOUT_CALL? POP_WITHOUT_PUSH? Or are these errors just > ignored by current wisdom?)? Both of those cases are meant to be covered by the "STACK_UNDERFLOW" reason code. > When the initial bytecode state item exceeds the UDVM memory, it > would be more informative get BYTECODES_TOO_LARGE instead of > SEGFAULT. Also, if the initial bytecode state item has > state_instruction outside UDVM memory INVALID_CODE_LOCATION > would be more informative than SEGFAULT. How could this happen? More specifically, how would such a piece of state be created? > Also, there is a security problem with ID_TOO_SHORT. If an > attacker can guess the initial 6 bytes of a state identifier, he > can quickly obtain the rest of the state ID with the help of > ID_TOO_SHORT. With a message including the state contents in, > for instance, a branch parameter of a SIP Via header, the > attacker can then obtain the state contents from UDVM host. So, > I'd recommend leaving out ID_TOO_SHORT. Instead of it, > STATE_NOT_FOUND should be returned. Alternatively, mention > ID_TOO_SHORT in "Security Considerations". That's a good point. Unless there are objections to doing so, I'll remove it. > Featuritis: > > What about including PC and the byte code of the failed > instruction in the NACK, like: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 1 1 1 | T | 0 | > +---+---+---+---+---+---+---+---+ > | | > : returned feedback item : > | | > +---+---+---+---+---+---+---+---+ > | code_len = 0 | > +---+---+---+---+---+---+---+---+ > | code_len = 0 | version = 1 | > +---+---+---+---+---+---+---+---+ > | Reason Code | > +---+---+---+---+---+---+---+---+ > | OPCODE of failed instruction | > +---+---+---+---+---+---+---+---+ > | PC-HI of failed instruction | > +---+---+---+---+---+---+---+---+ > | PC-LO of failed instruction | > +---+---+---+---+---+---+---+---+ > | | > : SHA-1 Hash of failed message : > | | > +---+---+---+---+---+---+---+---+ > | | > : Error Details : > | | > +---+---+---+---+---+---+---+---+ > > Figure 1: SigComp NACK Message Format It makes it NACKs three bytes larger, but I don't really see any harm in that. Since part of the rationale behind having this kind of mechanism is assistance in debugging, that seems worthwhile. If anyone objects to this addition, please speak up! > Featuritis 2: INTERNAL_ERROR > > """ > INTERNAL_ERROR > > UDVM encountered an unexpected condition that prevented it from > decompressing the message. > """ > > Featuritis 3: FRAMING_ERROR > > """ > FRAMING_ERROR > > UDVM encountered a framing error (unquoted 0xFF 80 .. 0xFF FE in > input stream.) > """ Okay, I've added both of these. > Nits: > > The description of BAD_BITORDER is a bit misleading - > input_bit_order is a 16-bit register, so I'd expect BAD_BITORDER > if any one of the upper 13 is set. I'd also write it > BAD_INPUT_BIT_ORDER. Yes, that was an oversight. I've renamed it and changed it to reflect the proper register width. > Spell out instructions in TOO_MANY_BITS_REQUESTED: > > """ > An INPUT-BITS or INPUT-HUFFMAN instruction was > encountered that > attempted to input more than 16 bits. > """ Fixed. > Spelling: Thanks. I ran a spell checker over it. (I Finally found 'aspell', which allows you to check XML-formatted documents. Yaay!) /a _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 10 20:54:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00525 for ; Wed, 10 Dec 2003 20:54: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 1AUG1j-0002rT-4d for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 20:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB1s3Pm010993 for rohc-archive@odin.ietf.org; Wed, 10 Dec 2003 20:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUG1i-0002rE-54 for rohc-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 20:54: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 UAA00522 for ; Wed, 10 Dec 2003 20:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUG1f-0007fs-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 20:53:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUG1e-0007fp-00 for rohc-web-archive@ietf.org; Wed, 10 Dec 2003 20:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUG1h-0002qy-7A; Wed, 10 Dec 2003 20:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUG0w-0002qV-MF for rohc@optimus.ietf.org; Wed, 10 Dec 2003 20:53: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 UAA00481 for ; Wed, 10 Dec 2003 20:53:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUG0t-0007f5-00 for rohc@ietf.org; Wed, 10 Dec 2003 20:53:11 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AUG0t-0007ee-00 for rohc@ietf.org; Wed, 10 Dec 2003 20:53:11 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBB1qcHQ013424 for ; Wed, 10 Dec 2003 19:52:38 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 19:52:38 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866CB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'rohc@ietf.org'" Date: Wed, 10 Dec 2003 19:52:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] New SigComp NACK draft 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 have updated the SigComp NACK draft to reflect comments received since the publication of draft-roach-sigcomp-nack-01. Until this appears in the internet-drafts repository, you can fetch a copy from: http://www.softarmor.com/~adam/ids/draft-ietf-rohc-sigcomp-nack-00.txt If you have commented on the earlier drafts, please check this latest revision to make certain that I have addressed all the known issues. Finally, I have had very little comment on the use of UDVM memory positions 10 and 11 for identification of the presence of the extensions in general, and the NACK extension in particular. Does this seem like a reasonable approach? (See section 2.4 of the current draft for further details). /a _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 11 02:16:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20278 for ; Thu, 11 Dec 2003 02:16:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUL3N-0005vw-C6 for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 02:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB7G55L022807 for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 02: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 1AUL3M-0005vm-LM for rohc-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 02: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 CAA20231 for ; Thu, 11 Dec 2003 02:16:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUL3I-0004dv-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 02:16:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUL3H-0004ds-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 02: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 1AUL3K-0005vP-GL; Thu, 11 Dec 2003 02: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 1AUL3E-0005tr-7y for rohc@optimus.ietf.org; Thu, 11 Dec 2003 02:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20190 for ; Thu, 11 Dec 2003 02:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUL35-0004dU-00 for rohc@ietf.org; Thu, 11 Dec 2003 02:15:47 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AUL2x-0004dO-00 for rohc@ietf.org; Thu, 11 Dec 2003 02:15:39 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBB7FdSs020235; Thu, 11 Dec 2003 08:15:39 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Dec 2003 08:15:39 +0100 Message-ID: From: =?iso-8859-1?Q?Fredrik_Lindstr=F6m_=28LU/EAB=29?= To: "'Yousuf.Saifullah@nokia.com'" , kristofer.sandlund@effnet.com, zhigang.c.liu@nokia.com Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Thu, 11 Dec 2003 08:15:13 +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 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 Yousuf I think these discriminator bits exist just for padding at the moment, = I don't know if the intension is to increase the number of replicate = formats. I have some more comments on the format (section 6.5.5.1 in the TCP = draft) see arrows (<--) below. Its just minor errors and I think the packet formats will be updated = soon. replicate_format_0 ::=3D =20 discriminator, % 4 bits format, % 1 bit <-- What is this = format bit for? ip_id.discriminator, % 1 bit ip_src_addr.discriminator, % 1 bit ip_dst_addr.discriminator, % 1 bit ip_tos.discriminator, % 1 bit <-- No field for = sending TOS below ip_ttl.discriminator, % 1 bit <-- No field for = sending TTL below tcp_src_port.discriminator, % 2 bits tcp_dst_port.discriminator, % 2 bits tcp_ack_number.discriminator, % 1 bit tcp_ecn_and_reserved.discriminator,% 1 bit order_flag, % 1 bit presence_flag, % 1 bit ip_dont_frag, % 1 bit tcp_flags_urg, % 1 bit tcp_flags_ack, % 1 bit tcp_flags_psh, % 1 bit tcp_flags_rsf, % 2 bits header_crc, % 8 bits <-- Which crc is = this and what is it =20 caculated over? msn, % 16 bits tcp_seq_number, % 32 bits ip_src_addr, % 0 or 32 bits ip_dst_addr, % 0 or 32 bits ip_id, % 0 or 16 bits tcp_src_port, % 0, 8 or 16 bits tcp_dst_port, % 0, 8 or 16 bits tcp_ack_number, % 0 or 32 bits tcp_ecn_and_reserved, % 0 or 8 bits <-- We should have format for TOS,TTL=20 and also for = tcp_window but observe that also a discriminator for = =20 window is missing. tcp_options, % variable no. of bits /Fredrik Lindstr=F6m -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of Yousuf.Saifullah@nokia.com Sent: den 11 december 2003 00:13 To: kristofer.sandlund@effnet.com; zhigang.c.liu@nokia.com Cc: Lars-Erik Jonsson (LU/EAB); mark.a.west@roke.co.uk; rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Hi Kristofer & Lars-Erik, Please find my answers in this email. My comments don't have any = indentation of ">".=20 Also, I have asked this before but I didn't get any answer. Could = anyone please tell me why discriminator in replicate_format_0 on Page = 32 of rohc-tcp-05 has 4 bits and only one value. replicate_format_0 ::=3D discriminator, % 4 = bits > -----Original Message----- > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: Wednesday, December 10, 2003 2:03 AM > To: Liu Zhigang.C (NRC/Dallas) > Cc: Saifullah Yousuf (NRC/Dallas); lars-erik.jonsson@ericsson.com; > mark.a.west@roke.co.uk; rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Zhigang & Yousuf, >=20 > Zhigang: > You make a number of valid points. I still belive that the=20 > largest part of the=20 > flows can be replicated by exact match, thus making n>1 for=20 > the common case. >=20 > Regaring n=3D50 being unreasonable, I did a quick test. > Using the "trafshow"=20 > (http://soft.risp.ru/trafshow/index_en.shtml) program that > shows open connections in realtime, I opended my web browser=20 > (Opera 7.21) to one=20 > of Sweden's most popular web sites, www.aftonbladet.se. What=20 > I got was something=20 > like 70 connections within a few seconds, even though I=20 > filtered to show only=20 > that specific host. Maybe not the best example (it could be=20 > an extreme case),=20 > but it shows that it definitely is not unrealistic for a very=20 > much used web page. > But maybe there's no point in discussing the finer points of=20 > HTTP, we can=20 > proably both make examples showing things one way or the=20 > other. Since it is just=20 > the three of us discussing this right now, I'd like to see=20 > what the others think=20 > before we continue this. >=20 > If it is to be added, I'd prefer if you had a more simple=20 > encoding (as you=20 > mention that you have prepared) that could only match a few=20 > of the most useful=20 > cases. I dislike this "variable number of bits" encoding. If=20 > you could have an=20 > enconding that always is a multiple of octets, then I'd be=20 > much more happy.=20 > We've tried to have as much byte-alignment as possible in the=20 > TCP packet=20 > formats, so it would help if this also was that. >=20 Please consider the following byte-aligned structure. For IPv4: =20 Option 1: Encoding will be in bytes. 2 bits for matched-len in bytes. = Three un-matched bytes is not sent for destination. I am considering = that detination is full match most of the time. matched-len for both = src and dest can be placed together. There will still be byte alignment = problem with the matched-len fields. ip_src_addr.matched_len % 0 (No Match & Full Match) or 2 bits ip_dest_addr.matched_len % 0 (No Match & Full Match)or 2 bits ip_src_addr, % 0 (Full Match); unmatched 8, 16 = or 24 bits; 32 bits (No Match) ip_dst_addr, % 0 (Full Match); unmatched 8 or 16 = bits ; 32 bits (No Match) Option 2: 2 bits for matched-len in bytes. unmatched bits would be 6, = 14, or 22 bits. There won't be any byte alignment problem with the = matched-len. ip_src_addr.matched_len % 0 (No Match & Full Match) or 2 bits ip_src_addr, % 0 (Full Match); unmatched 6, 12, = or 22 bits ; 32 bits (No Match) ip_dest_addr.matched_len % 0 (No Match & Full Match)or 2 bits ip_dst_addr, % 0 (Full Match); unmatched 6, 12, = or 22 bits ; 32 bits (No Match) I think option 2 is better, but I would let the WG decide. For IPv6:=20 4 bits for matched-len in bytes. unmatched bytes will be 1 to 15. = matched-len for both src & dest can be placed together and this creates = a byte alignment. ip_src_addr.matched_len % 0 (No Match & Full Match) or 4 bits ip_dest_addr.matched_len % 0 (No Match & Full Match)or 4 bits ip_src_addr, % 0 (Full Match); unmatched 8, 16, = 24 ... 120 bits; 128 bits (No Match) ip_dst_addr, % 0 (Full Match); unmatched 8, 16, = 24, ... 112 bits ; 128 bits (No Match) =20 > Yousuf>I would also suggest to evaluate the cost and gain for=20 > the TCP port #s > Yousuf>and use bits with maximum gain. Since, we are still=20 > discussing rohc-tcp > Yousuf>draft. TCP port #s are also using 2*n bits more for=20 > indicating port # > Yousuf>compression. If we use the same formula for the TCP=20 > port #s, which has 2 > Yousuf>bits for src and dest port discriminator. The 8 bit=20 > source and 8 bit > Yousuf>destination port matches results into the following=20 > formula, with the > Yousuf>same analysis as yours >=20 > Hmm.. I'm not sure my analysis really works on TCP ports.=20 > Here, we are likely to=20 > see the ephemeral port be prefix matched almost all the time,=20 > since the normal=20 > allocation scheme will be more or less sequential. Even if I open 50=20 > "near-simultaneous" connections, I won't be getting any exact=20 > matches on the=20 > port numbers. Due to this behavior, TCP ports "partial=20 > matching" makes more=20 > sense to me than addresses. >=20 Also, Lars-Erik wrote: > > This is another important key-point. I have been convinced that > it might happen rather often that many flows passing through > the same compressor/decompressor have the same source and/or > destination IP address. The case Kristofer exemplified above > is the typical example, and this would realistically happen > over a "compressed link", as compression is usually applied > on access links, where at least one IP address will be the > same for most connections. Having compression for port numbers > also makes sense as ports are usually sequentially assigned > and will thus "be close" to each other for all these parallel > connections.=20 >=20 > Although I can see cases when also IP addresses will "be close", > I do not think these cases are as obvious and common. Further, > for the cases I can see, I do not think compression is as > important, as these will not at all be comparable (in #'s) to > the example with HTTP multiple connections (as exemplified above).=20 >=20 The HTTP multiple connection example is already commented by Zhigang = that why it is not that frequent. I have said in my last posts that = limiting context replication to 1 host and 1 server is an unnecessary = limitation. We are totally ignoring another dimension of multiple hosts = over a "compressed link". I have given these cases before few times. = Please see the following post:=20 http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01853.h= tml Could you please tell me why these cases are not obvious and common. I = see them occuring more than multiple TCP connections between 1 host and = 1 server. The reason is the common use of HTTP 1.1, and also proxy, = would not let multiple TCP connections to occur. I have given this number before. I am repeating it here again. If we = have m multiple hosts in the system with compressible IP addresses, = then the saving is m*(gain per flow). The saving will be 55*m bits for = HTTP 1.1./IPv6.=20 Thanks, 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 Dec 11 04:22:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23161 for ; Thu, 11 Dec 2003 04:22:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUN1H-00032n-Ao for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 04:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB9M3PT011695 for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 04:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUN1G-00032Y-Gl for rohc-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 04: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 EAA23146 for ; Thu, 11 Dec 2003 04:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUN1D-0006V7-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 04:21:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUN1C-0006V4-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 04: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 1AUN1E-00032A-Ki; Thu, 11 Dec 2003 04: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 1AUN0b-00030g-RI for rohc@optimus.ietf.org; Thu, 11 Dec 2003 04:21: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 EAA23109 for ; Thu, 11 Dec 2003 04:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUN0Y-0006Tx-00 for rohc@ietf.org; Thu, 11 Dec 2003 04:21:18 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AUN0X-0006Tj-00 for rohc@ietf.org; Thu, 11 Dec 2003 04:21:17 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBB9LI8K016401; Thu, 11 Dec 2003 10:21:18 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Dec 2003 10:21:17 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Yousuf.Saifullah@nokia.com'" , kristofer.sandlund@effnet.com, zhigang.c.liu@nokia.com Cc: mark.a.west@roke.co.uk, rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Thu, 11 Dec 2003 10:20:45 +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: , Yousuf, > I have given this number before. I am repeating it here again. > If we have m multiple hosts in the system with compressible IP > addresses, then the saving is m*(gain per flow). The saving > will be 55*m bits for HTTP 1.1./IPv6. Consider the most common scenario for HC, i.e. compression over the last link to a single end host. There you usually only have ONE single host on the link, which means one address is always the same (replicable), while other addresses are totally random (only replicable when we have multiple connections to the same peer host). /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 11 10:18:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05613 for ; Thu, 11 Dec 2003 10:18:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSZm-0000IK-Bz for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 10:18:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFI20O001126 for rohc-archive@odin.ietf.org; Thu, 11 Dec 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 1AUSZm-0000I5-6s for rohc-web-archive@optimus.ietf.org; Thu, 11 Dec 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 KAA05572 for ; Thu, 11 Dec 2003 10:17:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSZk-0006E3-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 10:18:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUSZj-0006E0-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 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 1AUSZl-0000Hp-26; Thu, 11 Dec 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSZ2-0000Gl-8Y for rohc@optimus.ietf.org; Thu, 11 Dec 2003 10:17:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05497 for ; Thu, 11 Dec 2003 10:17:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSZ0-0006DU-00 for rohc@ietf.org; Thu, 11 Dec 2003 10:17:14 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUSYz-0006DQ-00 for rohc@ietf.org; Thu, 11 Dec 2003 10:17:13 -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 hBBFHCT23629 for ; Thu, 11 Dec 2003 17:17:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Dec 2003 17:17:11 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 17:17:11 +0200 Received: from localhost.localdomain (hed043-205.research.nokia.com [172.21.43.205]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA26767; Thu, 11 Dec 2003 17:17:16 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBBFGk9j009615; Thu, 11 Dec 2003 17:16:46 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hBBFGjZA009614; Thu, 11 Dec 2003 17:16:45 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Adam Roach Cc: "'Pekka Pessi'" , 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 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E866C8@dyn-tx-exch-001.dynamicsoft.com> (Adam Roach's message of "Wed, 10 Dec 2003 18:20:14 -0600") References: <9BF66EBF6BEFD942915B4D4D45C051F3E866C8@dyn-tx-exch-001.dynamicsoft.com> Date: Thu, 11 Dec 2003 17:16:45 +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: 11 Dec 2003 15:17:11.0516 (UTC) FILETIME=[D99C31C0:01C3BFF9] Subject: [rohc] Re: Comments to draft-roach-sigcomp-nack-01 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Adam Roach writes: >> This also means that the socket used to receive SIGCOMP messages >> should not be bound to INADDR_ANY. Not to mention in6addr_any. >I don't think this is necessarily an implication. As long as the >implementation can make certain that the response is sent from the >same IP address, that's all we really need. You are correct. However, it might be a good idea to advice the reader that the source IP address can usually determined by binding the local IP address. ... >> What about errors mentioned by RFC 3320 section 8.7 item 7 >> (RETURN_WITHOUT_CALL? POP_WITHOUT_PUSH? Or are these errors just >> ignored by current wisdom?)? >Both of those cases are meant to be covered by the "STACK_UNDERFLOW" >reason code. Ok. ... >> When the initial bytecode state item exceeds the UDVM memory, it >> would be more informative get BYTECODES_TOO_LARGE instead of >> SEGFAULT. Also, if the initial bytecode state item has >> state_instruction outside UDVM memory INVALID_CODE_LOCATION >> would be more informative than SEGFAULT. >How could this happen? More specifically, how would such a piece >of state be created? By state identifier collision, for instance. But I agree, the sender can deduct that from SEGFAULT. ... >> """ >> FRAMING_ERROR >> UDVM encountered a framing error (unquoted 0xFF 80 .. 0xFF FE in >> input stream.) >> """ >Okay, I've added both of these. It could also be mentioned that in the case of framing error, the SHA-1 hash is unusable. --Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 11 10:28:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06272 for ; Thu, 11 Dec 2003 10:28: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 1AUSjG-0000rN-Kx for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 10:27:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFRohE003305 for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 10:27:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSjE-0000r9-NJ for rohc-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 10:27: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 KAA06196 for ; Thu, 11 Dec 2003 10:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSiS-0006Wd-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 10:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUSiR-0006Wa-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 10:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSiS-0000o8-N9; Thu, 11 Dec 2003 10:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUShk-0000mY-3c for rohc@optimus.ietf.org; Thu, 11 Dec 2003 10:26:21 -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 KAA06132 for ; Thu, 11 Dec 2003 10:26:02 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUShX-0006US-00 for rohc@ietf.org; Thu, 11 Dec 2003 10:26:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUShX-0006UO-00 for rohc@ietf.org; Thu, 11 Dec 2003 10:26:03 -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 hBBFQ2822434 for ; Thu, 11 Dec 2003 17:26:02 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Dec 2003 17:26:02 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 07:25:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Thu, 11 Dec 2003 09:25:48 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398939@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO/tprb+9BSewd+TQG6Rd5Rd2p7BAAQoxIw To: , , Cc: X-OriginalArrivalTime: 11 Dec 2003 15:25:48.0406 (UTC) FILETIME=[0DB35960:01C3BFFB] 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 Fredrik, Thanks for the answer.=20 If the discriminator is only for padding, then we should utilize it for = compression. Instead of sending null 4 bits, why not use it for the 2 = additional bits of the src/dst discriminator. This will increase = compression efficiency without causing any cost (analysis from Kristofer = - = http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01877.ht= ml).=20 I don't see, how we can have multiple replicate_formats. Considering = that any optional feature can only be implemented by different profile. = If we define different formats, then how we are going to tell = compressor/decompressor which format to use. If someone sees it, then I = will appreciate a response. If not then we should take the discriminator = out and change its name to pad. You are right we are missing some other fields. Can the authors of = draft-ietf-rohc-tcp-05.txt comment on the other fields also? Regards, Yousuf > -----Original Message----- > From: ext Fredrik Lindstr=F6m (LU/EAB) > [mailto:fredrik.lindstrom@ericsson.com] > Sent: Thursday, December 11, 2003 1:15 AM > To: Saifullah Yousuf (NRC/Dallas); kristofer.sandlund@effnet.com; Liu > Zhigang.C (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Yousuf >=20 > I think these discriminator bits exist just for padding at=20 > the moment, I don't know if the intension is to increase the=20 > number of replicate formats. >=20 > I have some more comments on the format (section 6.5.5.1 in=20 > the TCP draft) see arrows (<--) below. > Its just minor errors and I think the packet formats will be=20 > updated soon. >=20 >=20 > replicate_format_0 ::=3D =20 > discriminator, % 4 bits > format, % 1 bit <-- What is=20 > this format bit for? > ip_id.discriminator, % 1 bit > ip_src_addr.discriminator, % 1 bit > ip_dst_addr.discriminator, % 1 bit > ip_tos.discriminator, % 1 bit <-- No=20 > field for sending TOS below > ip_ttl.discriminator, % 1 bit <-- No=20 > field for sending TTL below > tcp_src_port.discriminator, % 2 bits > tcp_dst_port.discriminator, % 2 bits > tcp_ack_number.discriminator, % 1 bit > tcp_ecn_and_reserved.discriminator,% 1 bit > order_flag, % 1 bit > presence_flag, % 1 bit > ip_dont_frag, % 1 bit > tcp_flags_urg, % 1 bit > tcp_flags_ack, % 1 bit > tcp_flags_psh, % 1 bit > tcp_flags_rsf, % 2 bits > header_crc, % 8 bits <-- Which=20 > crc is this and what is it =20 > caculated over? > msn, % 16 bits > tcp_seq_number, % 32 bits > ip_src_addr, % 0 or 32 bits > ip_dst_addr, % 0 or 32 bits > ip_id, % 0 or 16 bits > tcp_src_port, % 0, 8 or 16 bits > tcp_dst_port, % 0, 8 or 16 bits > tcp_ack_number, % 0 or 32 bits > tcp_ecn_and_reserved, % 0 or 8 bits > =09 > <-- We should have format for TOS,TTL=20 > and=20 > also for tcp_window but observe > =09 > that also a discriminator for =20 > =20 > =20 > window is missing. > tcp_options, % variable no. of bits >=20 > /Fredrik Lindstr=F6m >=20 > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Yousuf.Saifullah@nokia.com > Sent: den 11 december 2003 00:13 > To: kristofer.sandlund@effnet.com; zhigang.c.liu@nokia.com > Cc: Lars-Erik Jonsson (LU/EAB); mark.a.west@roke.co.uk; rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Kristofer & Lars-Erik, > Please find my answers in this email. My comments don't have=20 > any indentation of ">".=20 >=20 > Also, I have asked this before but I didn't get any answer.=20 > Could anyone please tell me why discriminator in=20 > replicate_format_0 on Page 32 of rohc-tcp-05 has 4 bits and=20 > only one value. >=20 > replicate_format_0 ::=3D discriminator, =20 > % 4 bits >=20 > > -----Original Message----- > > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > > Sent: Wednesday, December 10, 2003 2:03 AM > > To: Liu Zhigang.C (NRC/Dallas) > > Cc: Saifullah Yousuf (NRC/Dallas); lars-erik.jonsson@ericsson.com; > > mark.a.west@roke.co.uk; rohc@ietf.org > > Subject: Re: [rohc] IP Address Compression for Context Replication > >=20 > >=20 > > Hi Zhigang & Yousuf, > >=20 > > Zhigang: > > You make a number of valid points. I still belive that the=20 > > largest part of the=20 > > flows can be replicated by exact match, thus making n>1 for=20 > > the common case. > >=20 > > Regaring n=3D50 being unreasonable, I did a quick test. > > Using the "trafshow"=20 > > (http://soft.risp.ru/trafshow/index_en.shtml) program that=20 > > shows open connections in realtime, I opended my web browser=20 > > (Opera 7.21) to one=20 > > of Sweden's most popular web sites, www.aftonbladet.se. What=20 > > I got was something=20 > > like 70 connections within a few seconds, even though I=20 > > filtered to show only=20 > > that specific host. Maybe not the best example (it could be=20 > > an extreme case),=20 > > but it shows that it definitely is not unrealistic for a very=20 > > much used web page. > > But maybe there's no point in discussing the finer points of=20 > > HTTP, we can=20 > > proably both make examples showing things one way or the=20 > > other. Since it is just=20 > > the three of us discussing this right now, I'd like to see=20 > > what the others think=20 > > before we continue this. > >=20 > > If it is to be added, I'd prefer if you had a more simple=20 > > encoding (as you=20 > > mention that you have prepared) that could only match a few=20 > > of the most useful=20 > > cases. I dislike this "variable number of bits" encoding. If=20 > > you could have an=20 > > enconding that always is a multiple of octets, then I'd be=20 > > much more happy.=20 > > We've tried to have as much byte-alignment as possible in the=20 > > TCP packet=20 > > formats, so it would help if this also was that. > >=20 >=20 > Please consider the following byte-aligned structure. >=20 > For IPv4: > =20 > Option 1: Encoding will be in bytes. 2 bits for matched-len=20 > in bytes. Three un-matched bytes is not sent for destination.=20 > I am considering that detination is full match most of the=20 > time. matched-len for both src and dest can be placed=20 > together. There will still be byte alignment problem with the=20 > matched-len fields. >=20 > ip_src_addr.matched_len % 0 (No Match &=20 > Full Match) or 2 bits > ip_dest_addr.matched_len % 0 (No Match & Full=20 > Match)or 2 bits > ip_src_addr, % 0 (Full Match);=20 > unmatched 8, 16 or 24 bits; 32 bits (No Match) > ip_dst_addr, % 0 (Full Match);=20 > unmatched 8 or 16 bits ; 32 bits (No Match) >=20 >=20 > Option 2: 2 bits for matched-len in bytes. unmatched bits=20 > would be 6, 14, or 22 bits. There won't be any byte alignment=20 > problem with the matched-len. >=20 > ip_src_addr.matched_len % 0 (No Match &=20 > Full Match) or 2 bits > ip_src_addr, % 0 (Full Match);=20 > unmatched 6, 12, or 22 bits ; 32 bits (No Match) > ip_dest_addr.matched_len % 0 (No Match & Full=20 > Match)or 2 bits > ip_dst_addr, % 0 (Full Match);=20 > unmatched 6, 12, or 22 bits ; 32 bits (No Match) >=20 > I think option 2 is better, but I would let the WG decide. >=20 > For IPv6:=20 > 4 bits for matched-len in bytes. unmatched bytes will be 1 to=20 > 15. matched-len for both src & dest can be placed together=20 > and this creates a byte alignment. >=20 > ip_src_addr.matched_len % 0 (No Match &=20 > Full Match) or 4 bits > ip_dest_addr.matched_len % 0 (No Match & Full=20 > Match)or 4 bits > ip_src_addr, % 0 (Full Match);=20 > unmatched 8, 16, 24 ... 120 bits; 128 bits (No Match) > ip_dst_addr, % 0 (Full Match);=20 > unmatched 8, 16, 24, ... 112 bits ; 128 bits (No Match) >=20 > =20 >=20 >=20 >=20 > > Yousuf>I would also suggest to evaluate the cost and gain for=20 > > the TCP port #s > > Yousuf>and use bits with maximum gain. Since, we are still=20 > > discussing rohc-tcp > > Yousuf>draft. TCP port #s are also using 2*n bits more for=20 > > indicating port # > > Yousuf>compression. If we use the same formula for the TCP=20 > > port #s, which has 2 > > Yousuf>bits for src and dest port discriminator. The 8 bit=20 > > source and 8 bit > > Yousuf>destination port matches results into the following=20 > > formula, with the > > Yousuf>same analysis as yours > >=20 > > Hmm.. I'm not sure my analysis really works on TCP ports.=20 > > Here, we are likely to=20 > > see the ephemeral port be prefix matched almost all the time,=20 > > since the normal=20 > > allocation scheme will be more or less sequential. Even if=20 > I open 50=20 > > "near-simultaneous" connections, I won't be getting any exact=20 > > matches on the=20 > > port numbers. Due to this behavior, TCP ports "partial=20 > > matching" makes more=20 > > sense to me than addresses. > >=20 > Also, Lars-Erik wrote: > >=20 > > This is another important key-point. I have been convinced that > > it might happen rather often that many flows passing through > > the same compressor/decompressor have the same source and/or > > destination IP address. The case Kristofer exemplified above > > is the typical example, and this would realistically happen > > over a "compressed link", as compression is usually applied > > on access links, where at least one IP address will be the > > same for most connections. Having compression for port numbers > > also makes sense as ports are usually sequentially assigned > > and will thus "be close" to each other for all these parallel > > connections.=20 > >=20 > > Although I can see cases when also IP addresses will "be close", > > I do not think these cases are as obvious and common. Further, > > for the cases I can see, I do not think compression is as > > important, as these will not at all be comparable (in #'s) to > > the example with HTTP multiple connections (as exemplified above).=20 > >=20 >=20 > The HTTP multiple connection example is already commented by=20 > Zhigang that why it is not that frequent. I have said in my=20 > last posts that limiting context replication to 1 host and 1=20 > server is an unnecessary limitation. We are totally ignoring=20 > another dimension of multiple hosts over a "compressed link".=20 > I have given these cases before few times. Please see the=20 > following post:=20 > http://www1.ietf.org/mail-archive/working-groups/rohc/current/ msg01853.html Could you please tell me why these cases are not obvious and common. I = see them occuring more than multiple TCP connections between 1 host and = 1 server. The reason is the common use of HTTP 1.1, and also proxy, = would not let multiple TCP connections to occur. I have given this number before. I am repeating it here again. If we = have m multiple hosts in the system with compressible IP addresses, then = the saving is m*(gain per flow). The saving will be 55*m bits for HTTP = 1.1./IPv6.=20 Thanks, 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 Dec 11 15:40:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21989 for ; Thu, 11 Dec 2003 15:40:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUXaT-0007Tf-AA for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 15:39:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBKd553028737 for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 15:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUXaT-0007TQ-4H for rohc-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 15:39: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 PAA21829 for ; Thu, 11 Dec 2003 15:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUXaR-0007cV-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 15:39:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUXaR-0007cR-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 15:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUXaP-0007SW-R8; Thu, 11 Dec 2003 15:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUXZb-0007Ro-Eq for rohc@optimus.ietf.org; Thu, 11 Dec 2003 15:38:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21701; Thu, 11 Dec 2003 15:38:08 -0500 (EST) Message-Id: <200312112038.PAA21701@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, 11 Dec 2003 15:38:08 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-nack-00.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : A Negative Acknowledgement Mechanism for Signaling Compression Author(s) : A. Roach Filename : draft-ietf-rohc-sigcomp-nack-00.txt Pages : 20 Date : 2003-12-11 This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-nack-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-nack-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-nack-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-11160028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-nack-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-nack-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-11160028.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 Dec 11 19:40:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05188 for ; Thu, 11 Dec 2003 19:40:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUbLj-00032G-Km for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 19:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC0e7il011604 for rohc-archive@odin.ietf.org; Thu, 11 Dec 2003 19:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUbLi-00030x-0s for rohc-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 19:40: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 TAA05177 for ; Thu, 11 Dec 2003 19:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUbLg-0006mb-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 19:40:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUbLf-0006mX-00 for rohc-web-archive@ietf.org; Thu, 11 Dec 2003 19:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUbLg-00030g-8z; Thu, 11 Dec 2003 19: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 1AUbLE-0002zA-Bp for rohc@optimus.ietf.org; Thu, 11 Dec 2003 19:39: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 TAA05158 for ; Thu, 11 Dec 2003 19:39:34 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUbLC-0006le-00 for rohc@ietf.org; Thu, 11 Dec 2003 19:39:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUbLB-0006lb-00 for rohc@ietf.org; Thu, 11 Dec 2003 19:39:33 -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 hBC0dX823750 for ; Fri, 12 Dec 2003 02:39:33 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 02:39:34 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 16:39:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Thu, 11 Dec 2003 18:39:30 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139893D@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcO/yChlAm+RJ3+rS2KRTxLLNInItQAf0A9Q To: , , Cc: , X-OriginalArrivalTime: 12 Dec 2003 00:39:31.0320 (UTC) FILETIME=[6819B780:01C3C048] 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 Lars-Erik, My point is that multiple host scenario is not uncommon to ignore. We = should not limit the HC in the way you mentioned below. Moreover, the = decision should be made based on cost vs. gain analysis. Again over here = also we should not limit to HTTP 1.0 and IPv4. Regards, Yousuf > -----Original Message----- > From: ext Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Thursday, December 11, 2003 3:21 AM > To: Saifullah Yousuf (NRC/Dallas); kristofer.sandlund@effnet.com; Liu > Zhigang.C (NRC/Dallas) > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Yousuf, >=20 > > I have given this number before. I am repeating it here again. > > If we have m multiple hosts in the system with compressible IP > > addresses, then the saving is m*(gain per flow). The saving > > will be 55*m bits for HTTP 1.1./IPv6.=20 >=20 > Consider the most common scenario for HC, i.e. compression over > the last link to a single end host. There you usually only have > ONE single host on the link, which means one address is always > the same (replicable), while other addresses are totally random > (only replicable when we have multiple connections to the same > peer host). >=20 > /L-E >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 12 04:07:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01875 for ; Fri, 12 Dec 2003 04:07:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjGM-0000RN-Pi for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 04:07:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC976kM001678 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 04:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjGK-0000Qs-I5 for rohc-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 04:07:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01854 for ; Fri, 12 Dec 2003 04:07:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjGH-0000Fy-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 04:07:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUjGH-0000Fv-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 04:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjGG-0000Pp-Qh; Fri, 12 Dec 2003 04:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjFS-0000Oe-GS for rohc@optimus.ietf.org; Fri, 12 Dec 2003 04:06: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 EAA01845 for ; Fri, 12 Dec 2003 04:06:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjFP-0000FS-00 for rohc@ietf.org; Fri, 12 Dec 2003 04:06:07 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AUjFP-0000FP-00 for rohc@ietf.org; Fri, 12 Dec 2003 04:06: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 hBC967I2023789; Fri, 12 Dec 2003 10:06:07 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 10:06:07 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Yousuf.Saifullah@nokia.com'" Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Fri, 12 Dec 2003 10:05:29 +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: , Yousuf, Please explain in more detail the scenarios you are addressing, so that we can better understand the reason you think this is important. At the moment, people do not seem to think this is really needed, but we should make sure we do not decide before we have all understood the arguments (first then can we have an opinion on how to proceed). Thanks! /L-E > -----Original Message----- > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > Sent: den 12 december 2003 01:40 > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com; > zhigang.c.liu@nokia.com > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication > > > Hi Lars-Erik, > My point is that multiple host scenario is not uncommon to > ignore. We should not limit the HC in the way you mentioned > below. Moreover, the decision should be made based on cost > vs. gain analysis. Again over here also we should not limit > to HTTP 1.0 and IPv4. > > Regards, > Yousuf > > > -----Original Message----- > > From: ext Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson@ericsson.com] > > Sent: Thursday, December 11, 2003 3:21 AM > > To: Saifullah Yousuf (NRC/Dallas); > kristofer.sandlund@effnet.com; Liu > > Zhigang.C (NRC/Dallas) > > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > > Subject: RE: [rohc] IP Address Compression for Context Replication > > > > > > Yousuf, > > > > > I have given this number before. I am repeating it here again. > > > If we have m multiple hosts in the system with compressible IP > > > addresses, then the saving is m*(gain per flow). The saving > > > will be 55*m bits for HTTP 1.1./IPv6. > > > > Consider the most common scenario for HC, i.e. compression over > > the last link to a single end host. There you usually only have > > ONE single host on the link, which means one address is always > > the same (replicable), while other addresses are totally random > > (only replicable when we have multiple connections to the same > > peer host). > > > > /L-E > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 12 04:12:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01990 for ; Fri, 12 Dec 2003 04:12:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjLD-0000va-23 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 04:12:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC9C62q003441 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 04:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjLA-0000tM-Ly for rohc-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 04:12: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 EAA01982 for ; Fri, 12 Dec 2003 04:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjL7-0000Mg-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 04:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUjL7-0000Md-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 04:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjL8-0000ss-NI; Fri, 12 Dec 2003 04:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjKW-0000rz-Dv for rohc@optimus.ietf.org; Fri, 12 Dec 2003 04:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01961 for ; Fri, 12 Dec 2003 04:11:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjKS-0000Ly-00 for rohc@ietf.org; Fri, 12 Dec 2003 04:11:20 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AUjKR-0000Lq-00 for rohc@ietf.org; Fri, 12 Dec 2003 04:11:19 -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 hBC9BKI2025220; Fri, 12 Dec 2003 10:11:20 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 10:11:20 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Yousuf.Saifullah@nokia.com'" Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Fri, 12 Dec 2003 10:10:49 +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 don't see, how we can have multiple replicate_formats. Of course there can be different replicate formats. > Considering that any optional feature can only be implemented > by different profile. If we define different formats, then > how we are going to tell compressor/decompressor which format > to use. The indicator bits gives the format. I do not really understand what you mean by "optional feature can only be implemented by different profile". That is the case if you have a feature that both compressor and decompressor must be allowed to choose whether to support or not, but otherwise you can different kinds of formats using different compression methoods. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 12 04:45:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02873 for ; Fri, 12 Dec 2003 04:45:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjrD-0002Rd-Dx for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 04:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC9jBK6009393 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 04:45:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjr8-0002RM-8k for rohc-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 04:45: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 EAA02857 for ; Fri, 12 Dec 2003 04:45:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjr5-00014x-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 04:45:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUjr4-00014u-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 04:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjr4-0002Qy-VU; Fri, 12 Dec 2003 04:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUjqW-0002QY-RV for rohc@optimus.ietf.org; Fri, 12 Dec 2003 04:44: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 EAA02847 for ; Fri, 12 Dec 2003 04:44:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUjqT-00014f-00 for rohc@ietf.org; Fri, 12 Dec 2003 04:44:25 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AUjqS-00014a-00 for rohc@ietf.org; Fri, 12 Dec 2003 04:44:25 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBC9iL8K026213; Fri, 12 Dec 2003 10:44:24 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 10:44:21 +0100 Message-ID: From: =?iso-8859-1?Q?Fredrik_Lindstr=F6m_=28LU/EAB=29?= To: "'Yousuf.Saifullah@nokia.com'" , kristofer.sandlund@effnet.com, zhigang.c.liu@nokia.com Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Fri, 12 Dec 2003 10:43:45 +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 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 Yousuf "If the discriminator is only for padding, then we should utilize it = for compression. Instead of sending null 4 bits, why not use it for the = 2 additional bits of the src/dst discriminator. This will increase = compression efficiency without causing any cost (analysis from = Kristofer - = http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01877.h= tml)." Yes it is possible to use these bits, but I am quite sure that the = replicate packet is about to change so if it is possible after the = update I don't know. But on the other hand that's not the big problem = as I see it, the problem is to convince the working group that it is = worth adding your IP src, dest compression and then the IPR is a big = issue. Personally I am not convinced that it is worth it, of course = there are occasions where it is good, but how often do they occur and = how much will it save. I think that it is more likely that for example = two flows will have the same source address but random destination = address but I have not thought that much about it yet.=20 "I don't see, how we can have multiple replicate_formats. Considering = that any optional feature can only be implemented by different profile. = If we define different formats, then how we are going to tell = compressor/decompressor which format to use. If someone sees it, then I = will appreciate a response. If not then we should take the = discriminator out and change its name to pad." =20 What I meant was to have multiple packet formats for context = replication as with the normal CO-packets. -----Original Message----- From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] Sent: den 11 december 2003 16:26 To: Fredrik Lindstr=F6m (LU/EAB); kristofer.sandlund@effnet.com; zhigang.c.liu@nokia.com Cc: rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Hi Fredrik, Thanks for the answer.=20 If the discriminator is only for padding, then we should utilize it for = compression. Instead of sending null 4 bits, why not use it for the 2 = additional bits of the src/dst discriminator. This will increase = compression efficiency without causing any cost (analysis from = Kristofer - = http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01877.h= tml).=20 I don't see, how we can have multiple replicate_formats. Considering = that any optional feature can only be implemented by different profile. = If we define different formats, then how we are going to tell = compressor/decompressor which format to use. If someone sees it, then I = will appreciate a response. If not then we should take the = discriminator out and change its name to pad. You are right we are missing some other fields. Can the authors of = draft-ietf-rohc-tcp-05.txt comment on the other fields also? Regards, Yousuf > -----Original Message----- > From: ext Fredrik Lindstr=F6m (LU/EAB) > [mailto:fredrik.lindstrom@ericsson.com] > Sent: Thursday, December 11, 2003 1:15 AM > To: Saifullah Yousuf (NRC/Dallas); kristofer.sandlund@effnet.com; Liu > Zhigang.C (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Yousuf >=20 > I think these discriminator bits exist just for padding at=20 > the moment, I don't know if the intension is to increase the=20 > number of replicate formats. >=20 > I have some more comments on the format (section 6.5.5.1 in=20 > the TCP draft) see arrows (<--) below. > Its just minor errors and I think the packet formats will be=20 > updated soon. >=20 >=20 > replicate_format_0 ::=3D =20 > discriminator, % 4 bits > format, % 1 bit <-- What is=20 > this format bit for? > ip_id.discriminator, % 1 bit > ip_src_addr.discriminator, % 1 bit > ip_dst_addr.discriminator, % 1 bit > ip_tos.discriminator, % 1 bit <-- No=20 > field for sending TOS below > ip_ttl.discriminator, % 1 bit <-- No=20 > field for sending TTL below > tcp_src_port.discriminator, % 2 bits > tcp_dst_port.discriminator, % 2 bits > tcp_ack_number.discriminator, % 1 bit > tcp_ecn_and_reserved.discriminator,% 1 bit > order_flag, % 1 bit > presence_flag, % 1 bit > ip_dont_frag, % 1 bit > tcp_flags_urg, % 1 bit > tcp_flags_ack, % 1 bit > tcp_flags_psh, % 1 bit > tcp_flags_rsf, % 2 bits > header_crc, % 8 bits <-- Which=20 > crc is this and what is it =20 > caculated = over? > msn, % 16 bits > tcp_seq_number, % 32 bits > ip_src_addr, % 0 or 32 bits > ip_dst_addr, % 0 or 32 bits > ip_id, % 0 or 16 bits > tcp_src_port, % 0, 8 or 16 bits > tcp_dst_port, % 0, 8 or 16 bits > tcp_ack_number, % 0 or 32 bits > tcp_ecn_and_reserved, % 0 or 8 bits > =09 > <-- We should have format for TOS,TTL=20 > and=20 > also for tcp_window but observe > =09 > that also a discriminator for =20 > =20 > =20 > window is missing. > tcp_options, % variable no. of bits >=20 > /Fredrik Lindstr=F6m >=20 > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Yousuf.Saifullah@nokia.com > Sent: den 11 december 2003 00:13 > To: kristofer.sandlund@effnet.com; zhigang.c.liu@nokia.com > Cc: Lars-Erik Jonsson (LU/EAB); mark.a.west@roke.co.uk; rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi Kristofer & Lars-Erik, > Please find my answers in this email. My comments don't have=20 > any indentation of ">".=20 >=20 > Also, I have asked this before but I didn't get any answer.=20 > Could anyone please tell me why discriminator in=20 > replicate_format_0 on Page 32 of rohc-tcp-05 has 4 bits and=20 > only one value. >=20 > replicate_format_0 ::=3D discriminator, =20 > % 4 bits >=20 > > -----Original Message----- > > From: ext Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > > Sent: Wednesday, December 10, 2003 2:03 AM > > To: Liu Zhigang.C (NRC/Dallas) > > Cc: Saifullah Yousuf (NRC/Dallas); lars-erik.jonsson@ericsson.com; > > mark.a.west@roke.co.uk; rohc@ietf.org > > Subject: Re: [rohc] IP Address Compression for Context Replication > >=20 > >=20 > > Hi Zhigang & Yousuf, > >=20 > > Zhigang: > > You make a number of valid points. I still belive that the=20 > > largest part of the=20 > > flows can be replicated by exact match, thus making n>1 for=20 > > the common case. > >=20 > > Regaring n=3D50 being unreasonable, I did a quick test. > > Using the "trafshow"=20 > > (http://soft.risp.ru/trafshow/index_en.shtml) program that=20 > > shows open connections in realtime, I opended my web browser=20 > > (Opera 7.21) to one=20 > > of Sweden's most popular web sites, www.aftonbladet.se. What=20 > > I got was something=20 > > like 70 connections within a few seconds, even though I=20 > > filtered to show only=20 > > that specific host. Maybe not the best example (it could be=20 > > an extreme case),=20 > > but it shows that it definitely is not unrealistic for a very=20 > > much used web page. > > But maybe there's no point in discussing the finer points of=20 > > HTTP, we can=20 > > proably both make examples showing things one way or the=20 > > other. Since it is just=20 > > the three of us discussing this right now, I'd like to see=20 > > what the others think=20 > > before we continue this. > >=20 > > If it is to be added, I'd prefer if you had a more simple=20 > > encoding (as you=20 > > mention that you have prepared) that could only match a few=20 > > of the most useful=20 > > cases. I dislike this "variable number of bits" encoding. If=20 > > you could have an=20 > > enconding that always is a multiple of octets, then I'd be=20 > > much more happy.=20 > > We've tried to have as much byte-alignment as possible in the=20 > > TCP packet=20 > > formats, so it would help if this also was that. > >=20 >=20 > Please consider the following byte-aligned structure. >=20 > For IPv4: > =20 > Option 1: Encoding will be in bytes. 2 bits for matched-len=20 > in bytes. Three un-matched bytes is not sent for destination.=20 > I am considering that detination is full match most of the=20 > time. matched-len for both src and dest can be placed=20 > together. There will still be byte alignment problem with the=20 > matched-len fields. >=20 > ip_src_addr.matched_len % 0 (No Match &=20 > Full Match) or 2 bits > ip_dest_addr.matched_len % 0 (No Match & Full=20 > Match)or 2 bits > ip_src_addr, % 0 (Full Match);=20 > unmatched 8, 16 or 24 bits; 32 bits (No Match) > ip_dst_addr, % 0 (Full Match);=20 > unmatched 8 or 16 bits ; 32 bits (No Match) >=20 >=20 > Option 2: 2 bits for matched-len in bytes. unmatched bits=20 > would be 6, 14, or 22 bits. There won't be any byte alignment=20 > problem with the matched-len. >=20 > ip_src_addr.matched_len % 0 (No Match &=20 > Full Match) or 2 bits > ip_src_addr, % 0 (Full Match);=20 > unmatched 6, 12, or 22 bits ; 32 bits (No Match) > ip_dest_addr.matched_len % 0 (No Match & Full=20 > Match)or 2 bits > ip_dst_addr, % 0 (Full Match);=20 > unmatched 6, 12, or 22 bits ; 32 bits (No Match) >=20 > I think option 2 is better, but I would let the WG decide. >=20 > For IPv6:=20 > 4 bits for matched-len in bytes. unmatched bytes will be 1 to=20 > 15. matched-len for both src & dest can be placed together=20 > and this creates a byte alignment. >=20 > ip_src_addr.matched_len % 0 (No Match &=20 > Full Match) or 4 bits > ip_dest_addr.matched_len % 0 (No Match & Full=20 > Match)or 4 bits > ip_src_addr, % 0 (Full Match);=20 > unmatched 8, 16, 24 ... 120 bits; 128 bits (No Match) > ip_dst_addr, % 0 (Full Match);=20 > unmatched 8, 16, 24, ... 112 bits ; 128 bits (No Match) >=20 > =20 >=20 >=20 >=20 > > Yousuf>I would also suggest to evaluate the cost and gain for=20 > > the TCP port #s > > Yousuf>and use bits with maximum gain. Since, we are still=20 > > discussing rohc-tcp > > Yousuf>draft. TCP port #s are also using 2*n bits more for=20 > > indicating port # > > Yousuf>compression. If we use the same formula for the TCP=20 > > port #s, which has 2 > > Yousuf>bits for src and dest port discriminator. The 8 bit=20 > > source and 8 bit > > Yousuf>destination port matches results into the following=20 > > formula, with the > > Yousuf>same analysis as yours > >=20 > > Hmm.. I'm not sure my analysis really works on TCP ports.=20 > > Here, we are likely to=20 > > see the ephemeral port be prefix matched almost all the time,=20 > > since the normal=20 > > allocation scheme will be more or less sequential. Even if=20 > I open 50=20 > > "near-simultaneous" connections, I won't be getting any exact=20 > > matches on the=20 > > port numbers. Due to this behavior, TCP ports "partial=20 > > matching" makes more=20 > > sense to me than addresses. > >=20 > Also, Lars-Erik wrote: > >=20 > > This is another important key-point. I have been convinced that > > it might happen rather often that many flows passing through > > the same compressor/decompressor have the same source and/or > > destination IP address. The case Kristofer exemplified above > > is the typical example, and this would realistically happen > > over a "compressed link", as compression is usually applied > > on access links, where at least one IP address will be the > > same for most connections. Having compression for port numbers > > also makes sense as ports are usually sequentially assigned > > and will thus "be close" to each other for all these parallel > > connections.=20 > >=20 > > Although I can see cases when also IP addresses will "be close", > > I do not think these cases are as obvious and common. Further, > > for the cases I can see, I do not think compression is as > > important, as these will not at all be comparable (in #'s) to > > the example with HTTP multiple connections (as exemplified above).=20 > >=20 >=20 > The HTTP multiple connection example is already commented by=20 > Zhigang that why it is not that frequent. I have said in my=20 > last posts that limiting context replication to 1 host and 1=20 > server is an unnecessary limitation. We are totally ignoring=20 > another dimension of multiple hosts over a "compressed link".=20 > I have given these cases before few times. Please see the=20 > following post:=20 > http://www1.ietf.org/mail-archive/working-groups/rohc/current/ msg01853.html Could you please tell me why these cases are not obvious and common. I = see them occuring more than multiple TCP connections between 1 host and = 1 server. The reason is the common use of HTTP 1.1, and also proxy, = would not let multiple TCP connections to occur. I have given this number before. I am repeating it here again. If we = have m multiple hosts in the system with compressible IP addresses, = then the saving is m*(gain per flow). The saving will be 55*m bits for = HTTP 1.1./IPv6.=20 Thanks, 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 Fri Dec 12 13:23:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18859 for ; Fri, 12 Dec 2003 13:23: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 1AUrwM-0008Lc-N5 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 13:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCIN2Rl032084 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 13:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrwM-0008LP-Ju for rohc-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 13:23: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 NAA18849 for ; Fri, 12 Dec 2003 13:22:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrwK-0003P7-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 13:23:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUrwK-0003P4-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 13:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrwL-0008L0-73; Fri, 12 Dec 2003 13:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrwG-0008Kk-T2 for rohc@optimus.ietf.org; Fri, 12 Dec 2003 13:22:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18843; Fri, 12 Dec 2003 13:22:52 -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 1AUrwE-0003Os-00; Fri, 12 Dec 2003 13:22:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUrwE-0003Oi-00; Fri, 12 Dec 2003 13:22:54 -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 hBCIMqH06680; Fri, 12 Dec 2003 20:22:52 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 20:22: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, 12 Dec 2003 10:22:05 -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: RE: [rohc] IP Address Compression for Context Replication X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 12 Dec 2003 13:22:03 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E91E@ajebe001.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcPAj3+GI+jb/BV5TZKaev9kPOSWVAASdmZA To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 18:22:05.0078 (UTC) FILETIME=[D84D2B60:01C3C0DC] 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 Lars-Erik, One scenario is the mobile router case. I think Yousuf already mentioned this a few times. But for some reason, it seems it has been ignored. The scenario is quite simple: a subnet behind a router which connects=20 to the Internet via a bandwidth-limited link. For example, a PAN = (personal area network) or a subnet on a train, plane, etc. ROHC can reside in the router to compress headers that are sent over the link. There is already a related WG called nemo: http://www.ietf.org/html.charters/nemo-charter.html. You can find more=20 details there. But above few words should already give you a good = picture. Even for case of last-link header compression, IP address compression is also useful if the endpoint can refer to a context that contains at least IP address prefix. It is true that the ROHC channels are=20 different between different endpoints and the HC entity on the=20 network side. So this is a small technical issue on how to refer to a context from another channel. But, one simple solution could be to=20 use a common context that is independent of channels. BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Lars-Erik Jonsson (LU/EAB) > Sent: December 12, 2003 03:05 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Yousuf, >=20 > Please explain in more detail the scenarios you are addressing, > so that we can better understand the reason you think this is > important. At the moment, people do not seem to think this is > really needed, but we should make sure we do not decide before > we have all understood the arguments (first then can we have an > opinion on how to proceed). >=20 > Thanks! > /L-E >=20 > > -----Original Message----- > > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > > Sent: den 12 december 2003 01:40 > > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com; > > zhigang.c.liu@nokia.com > > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > > Subject: RE: [rohc] IP Address Compression for Context Replication > >=20 > >=20 > > Hi Lars-Erik, > > My point is that multiple host scenario is not uncommon to=20 > > ignore. We should not limit the HC in the way you mentioned=20 > > below. Moreover, the decision should be made based on cost=20 > > vs. gain analysis. Again over here also we should not limit=20 > > to HTTP 1.0 and IPv4. > >=20 > > Regards, > > Yousuf > >=20 > > > -----Original Message----- > > > From: ext Lars-Erik Jonsson (LU/EAB) > > > [mailto:lars-erik.jonsson@ericsson.com] > > > Sent: Thursday, December 11, 2003 3:21 AM > > > To: Saifullah Yousuf (NRC/Dallas);=20 > > kristofer.sandlund@effnet.com; Liu > > > Zhigang.C (NRC/Dallas) > > > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > > > Subject: RE: [rohc] IP Address Compression for Context Replication > > >=20 > > >=20 > > > Yousuf, > > >=20 > > > > I have given this number before. I am repeating it here again. > > > > If we have m multiple hosts in the system with compressible IP > > > > addresses, then the saving is m*(gain per flow). The saving > > > > will be 55*m bits for HTTP 1.1./IPv6.=20 > > >=20 > > > Consider the most common scenario for HC, i.e. compression over > > > the last link to a single end host. There you usually only have > > > ONE single host on the link, which means one address is always > > > the same (replicable), while other addresses are totally random > > > (only replicable when we have multiple connections to the same > > > peer host). > > >=20 > > > /L-E > > >=20 > >=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 Fri Dec 12 17:37:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00344 for ; Fri, 12 Dec 2003 17:37:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvuD-0004LD-6K for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 17:37:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMb4KZ016673 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 17:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvuB-0004Ki-WF for rohc-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:37: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 RAA00309 for ; Fri, 12 Dec 2003 17:36:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvu9-0003Ba-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 17:37:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUvu9-0003BX-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 17:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvu9-0004KH-MR; Fri, 12 Dec 2003 17:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvtU-0004JZ-Vl for rohc@optimus.ietf.org; Fri, 12 Dec 2003 17:36:21 -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 RAA00298 for ; Fri, 12 Dec 2003 17:36:16 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvtS-0003B1-00 for rohc@ietf.org; Fri, 12 Dec 2003 17:36:18 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUvtR-0003Ay-00 for rohc@ietf.org; Fri, 12 Dec 2003 17:36:18 -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 hBCMaHH21136 for ; Sat, 13 Dec 2003 00:36:17 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 00:36:19 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 14:35:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Fri, 12 Dec 2003 16:35:39 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139893F@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcPAj+rElklOClBbSuiPbTgq8LvMjAAYHV4w To: , Cc: X-OriginalArrivalTime: 12 Dec 2003 22:35:49.0384 (UTC) FILETIME=[4AB1E880:01C3C100] 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 Lars-Erik and Fredrick, Please see my response below. > -----Original Message----- > From: ext Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Friday, December 12, 2003 3:05 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Yousuf, >=20 > Please explain in more detail the scenarios you are addressing, > so that we can better understand the reason you think this is > important. At the moment, people do not seem to think this is > really needed, but we should make sure we do not decide before > we have all understood the arguments (first then can we have an > opinion on how to proceed). >=20 > Thanks! > /L-E >=20 Zhigang has explained the mobile router, which I think is important for = consideration. I will explain some other. Compressed link between two gateways: e.g. in cellular network Base = Station Controller and Base Transceiver Station could have a satellite = link. In this case we can use IP address compression between multiple = hosts. A group of devices, e.g. bluetooth devices, forming personal area = network, which are connected through a device, e.g. phone, to an = external network. It is possible the devices will have similar IP = addresses, so they can be routed through phone. If the compressed link = is between =20 The above scenarios should help in understanding the need for IP address = compression.=20 The specs should be designed to efficiently support foreseeable = scenarios also, not just the existing ones.=20 > -----Original Message----- > From: ext Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Friday, December 12, 2003 3:11 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > > I don't see, how we can have multiple replicate_formats. >=20 > Of course there can be different replicate formats. >=20 > > Considering that any optional feature can only be implemented=20 > > by different profile. If we define different formats, then=20 > > how we are going to tell compressor/decompressor which format=20 > > to use. >=20 > The indicator bits gives the format. I do not really understand > what you mean by "optional feature can only be implemented by > different profile". That is the case if you have a feature that > both compressor and decompressor must be allowed to choose > whether to support or not, but otherwise you can different > kinds of formats using different compression methoods. >=20 > /L-E >=20 I may have misunderstood. Where is that "indicator bits"? I don't see in = rohc-tcp-05. Are you talking about the "discriminator" field? OK! There are two cases for making a feature optional. One mentioned by = you in the above para. The other case is that we make both compressor = and decompressor use another replicate_format for the IP Address = Compression. In this way, even if the replicate_format_0 does not have = any space for the 2 additional bits of the src/dest IP address = discriminator, the new replicate format would have. The advantage is = that in the cases where IP address compression is not needed, there = won't be any cost for carrying these two additonal bits. In the cases, = where IP address compression is used, it will save much more than 2 bits = to justify the cost. We can define replicate_format_1 for IP address = compression, if there is no spare bit available in replicate_format_0 = (which still need to be seen). The IPR status is changed to "non-assertive", as I mentioned in an = earlier email. Therefore, implementation on both compressor and = decompressor should not be a concern. Please consider this point also.=20 Thanks, Yousuf =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Dec 12 19:54:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06203 for ; Fri, 12 Dec 2003 19:54:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUy2l-0001gG-Th for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 19:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBD0s3MN006454 for rohc-archive@odin.ietf.org; Fri, 12 Dec 2003 19:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUy2l-0001fz-Pd for rohc-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 19:54: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 TAA06181 for ; Fri, 12 Dec 2003 19:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUy2j-00069r-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 19:54:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUy2j-00069h-00 for rohc-web-archive@ietf.org; Fri, 12 Dec 2003 19:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUy2j-0001eX-Lb; Fri, 12 Dec 2003 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUy2P-0001dX-P0 for rohc@optimus.ietf.org; Fri, 12 Dec 2003 19:53: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 TAA06167 for ; Fri, 12 Dec 2003 19:53:39 -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 1AUy2N-00069C-00 for rohc@ietf.org; Fri, 12 Dec 2003 19:53:40 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUy2K-000698-00 for rohc@ietf.org; Fri, 12 Dec 2003 19:53:39 -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 hBD0raH23792 for ; Sat, 13 Dec 2003 02:53:36 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 02:53:35 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 18:53:34 -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] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 12 Dec 2003 19:53:32 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E920@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcOvta5ZK2s/tQtbRxqGIIIzv5D7cARWZYqA To: , Cc: , X-OriginalArrivalTime: 13 Dec 2003 00:53:34.0498 (UTC) FILETIME=[89163820:01C3C113] 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, Unfortunately, I couldn't spend time on this issue and will be on vacation starting next Monday until after new year. This has been a quite good discussion since it revealed things we really=20 haven't had chance to elaborate. Just a quick summary of what we agreed (or seemed so): 1) RFC 3320 does NOT allow multiplexing of SigComp and non-SigComp messages over the same TCP connection. Period. 2) The question is whether multiplexing is needed. 3) The mechanics of doing the multiplexing is clear. 4) Multiplexing is a new requirement, as the receiving SigComp endpoint has to behave differently. 5) A very simple stateless bytecode can be used to carry an uncompressed SIP message in a SigComp message. This can recover SigComp failures due to loss of sync on states. The rest is still more or less in debate, or unclear: single TCP connection, 64KB upper limit of UDVM output, UDVM failure itself,=20 security, etc. I'd encourage more pointed discussions from both sides so that we can reach a conclusion. Have a good holiday season! Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Dec 15 07:38:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05505 for ; Mon, 15 Dec 2003 07:38:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrzC-0001AK-9n for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 07:38:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCc6UU004474 for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 07:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrzB-0001A5-9G for rohc-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:38: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 HAA05499 for ; Mon, 15 Dec 2003 07:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVrzA-0003Pt-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 07:38:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVrzA-0003Pp-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 07:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrz8-00019c-9z; Mon, 15 Dec 2003 07:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVryn-00014F-Dt for rohc@optimus.ietf.org; Mon, 15 Dec 2003 07:37:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05487 for ; Mon, 15 Dec 2003 07:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVrym-0003O2-00 for rohc@ietf.org; Mon, 15 Dec 2003 07:37:40 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AVryl-0003Nz-00 for rohc@ietf.org; Mon, 15 Dec 2003 07:37:40 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBFCbcSs027417 for ; Mon, 15 Dec 2003 13:37:38 +0100 (MET) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW650M04; Mon, 15 Dec 2003 13:38:46 +0100 Received: by lms001.lu.erisoft.se id NAA16955; Mon, 15 Dec 2003 13:37:40 +0100 (MET) Message-ID: <3FDDABC7.D9581EAB@ericsson.com> Date: Mon, 15 Dec 2003 13:40:39 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <025E7DD4182874489CC2F61EE0FA19CE0139893F@daebe004.americas.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id hBFCbcSs027417 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, I went through the mail exchanges regarding this topic and here are my opinions and conclusions. Hopefully this can help bringing the discussion to a closing. PREFIX-Match ------------ I agree that a prefix match can occur in some _specific_ cases. However, this is not a typical scenario and thus my feeling is that there is no strong motivation to "optimize" ROHC-CR for this (furthermore with consideration that CR itself is already an optimization of the existing context initialization procedure). From the discussions, it seems that in the case of: - IPv4 with either HTTP1.0 or HTTP1.1, it has been agreed that there=20 would be no significant gain to include IP address compression; - IPv6 with HTTP1.0 (multiple TCP connections), the potential gain would=20 be very small, if any; - IPv6 with HTTP1.1 (persistent TCP connection), there could be some=20 gain - however in such case we are talking about the initialization of=20 a single connection, and the 2-3 first packets (IR-CR). However the=20 (lack of) applicability of IP address compression (see a later point=20 in this mail) makes this potential gain negligible in my opinion. =20 Therefore, before even considering how many bits we could save _when_ this would occur, I am much more interested in knowing how frequently PREFIX-matching can *realistically* occur. My opinion is that this is a very marginal case. SUFFIX-Match ------------ Zhigang.Liu@nokia.com wrote: > I honestly don't know how often "suffix match" will occur, > but think it's something useful to plan in protocol.=20 I strongly doubt that a suffix match (e.g. part or all of the interface ID) will occur in any scenario, other than due to pure coincidence. I don't think we should design compression on such basis. EXACT-match ----------- I believe that this will be the most common scenario for replicating one or both IP addresses. This is the scenario addressed by ROHC-CR. Overhead -------- Some discriminators in the current IR-CR packets are currently longer than necessary. This is in order to make the packet formats byte-aligned. As the packet formats will soon be updated, there is no guarantee that these bits will still be padding bits. This is thus not an argument for adding IP address compression if the gain is not worth it. Gains ----- Yousuf.Saifullah@nokia.com wrote: > We are totally ignoring another dimension of multiple hosts. > In your equations we are only comparing n flows between 1 > host and 1 server. If we have m multiple hosts in the system > with compressible IP addresses. The saving will be 55*m bits > for HTTP 1.1./IPv6. The theoretical value of m could be 2^64, > but we can reasonably pick a value in multiples of tens of > thousands. Let's say if we pick, 10,000. has been a working group document since March 2002. This is where the type of field behavior to be addressed by TCP header compression has been discussed extensively.=20 Section 6.5 specifically and clearly states that for short-lived flows (i.e. the problem space for context replication), what is to be considered is multiple TCP connections between the same pair of hosts. So it is no surprise that this is the focus of ROHC-CR. The case of "multiple hosts", would it be of any relevance at all, must be discussed and agreed by the working group before we can consider it an argument and so far I cannot see a strong case for it.=20 > This would give a saving of 550,000 bits. (...).=20 Yousuf.Saifullah@nokia.com wrote: > My point is that multiple host scenario is not uncommon to > ignore. We should not limit the HC in the way you mentioned > below. Moreover, the decision should be made based on cost > vs. gain analysis. Again over here also we should not limit > to HTTP 1.0 and IPv4. Not including IP Address compression does not limit the HC in any way. Please keep some context regarding the very limited applicability of this proposal. IPv4 or IPv6 flows using either HTTP1.0 or HTTP1.1 can still use context replication efficiently in the most expected cases. Regarding cost vs. gain analysis - I agree! - and see also my next comment on applicability and the last section of this mail where I add "based on agreed requirements" as well... Applicability/Scenarios ----------------------- Zhigang.Liu@nokia.com wrote: > This brings another simple example: HTTP 1.1 proxy server, > regardless if the origin server supports HTTP 1.1. A proxy > server is quite typical configuration for a subnet. I am quite confused here - isn't this also speaking in favor of EXACT-match of the IP address as the most commonly expected scenario, thus defeating the argument in itself? Zhigang.Liu@nokia.com wrote: > First, I don't think n=3D50 (i.e. 50 simultaneous TCP connections) > is realistic.=20 > > Second, the whole purpose or usefulness of TCP/IP HC is to > reduce header overhead. Then, why would a client open many TCP > connections to the same server and thus introduce extra header > overhead/context, instead of using one persistant connection? > It would look to me like creating problems and then solving it. > It doen't make sense to me. I agree! It is much smarter to use persistent connections. When doing so, the number of new contexts to be initialized is less, thus much fewer IR-CR would be sent and thus optimizing the cases where n=3D1 is of little significance. In my opinion this means that the applicability of IP Address compression is now even less motivated. Zhigang.Liu@nokia.com wrote: > I don't know what is the current distribution between HTTP > 1.0 and 1.1. But based on my knowledge, HTTP 1.1 used more > and more to optimize performance. And for the simple reasons > I gave above, it doesn't make sense to me to implement TCP/IP > HC without eliminating the root of problems: too many TCP > connections incurred by HTTP 1.0. I think that it makes more sense for ROHC-CR to be particularly well-suited for when that specific "problem" is occurring. And the most commonly expected case is still when EXACT-match of the IP address occurs anyway. Zhigang.Liu@nokia.com wrote: > As to IPv6 vs v4, my guess is that IPv4 will stay for > sometime. But IPv6 will pick up, at least that is what I > heard here in IETF and some other standardization > orgonaizations. Regardless of what is current situaiton, > a viable TCP/IP HC protocol should have a good handle of > IPv6. As to IPv4, IP address compression still brings > benifigs, though small. I believe ROHC-TCP is viable by itself. ROHC-CR is an optimization for ROHC-TCP that is also applicable to other profiles, and it is particularly welcome for the TCP profile. Context replication targets the initialization procedure, so keep in mind that we are talking about 2-3 initial packets in most cases, not an optimization of the entire compressed flow. Therefore I agree with you - IP address compression bring only small benefits - and I will conclude also that this is not often applicable and when so, only for a small number of packets within the header compressed flow. Finally, I must say that I fail to understand from the proponents of this solution a clear, realistic and useful scenario with a significant gain. Optional features ----------------- Yousuf.Saifullah@nokia.com wrote: > I don't see, how we can have multiple replicate_formats. Considering > that any optional feature can only be implemented by different > profile. If we define different formats, then how we are going to Defining different formats and defining which ones are used is not a problem - multiple packet formats must however all be supported by at least the decompressor, therefore "multiple packet formats" is no equivalent to "optional feature". For a feature to be optional, it must be possible for a decompressor not to implement it without possibility for the compressor to use the feature, thus implying some form of beforehand negotiation (which could take the form of the definition of different profiles, one supporting the feature - the other not). ROHC-TCP/CR requirements ------------------------ Finally, and certainly not least, I'd like to remind that a requirement has been explicitly _stated_, _motivated_ and *agreed* by the working group in terms of IPRs with relation to ROHC-TCP and ROHC-CR, from draft-ietf-rohc-tcp-requirements-06.txt - section 2.5 - "Requirements on ROHC TCP/IP Header Compression". (I am copy-pasting it here for everyone's convenience) http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-requirements-06.t= xt 2.5. Intellectual Property Rights (IPR) The ROHC WG must spend effort to achieve a high degree of confidence that there is no IPR covering a final compression solution for TCP. Justification: Currently there is no TCP header compression scheme available that can efficiently compress the packet headers of modern TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill this gap by providing a ROHC TCP scheme that is applicable in the wide area Internet, not only over error-prone radio links. It must thus attempt to be as future-proof as possible, and only unencumbered solutions will be acceptable to the Internet at large. This section has been present since from June 20, 2001, where it was agreed and included by the WG. To not meet it requires a particularly strong case, which is not true for IP address compression. =20 My opinion/conclusions ---------------------- It is my opinion, and this in addition to the technical discussions that I have seen so far regarding this on the mailing list, that IP Address compression is *very* marginal in terms of: 1) potential compression gain 2) applicability (e.g. _when_ it can be used to some gain). It thus seems clear that it cannot be considered as a "core" functionality _required_ for ROHC-CR, and therefore I support the many who have so far expressed objections and motivations against including this. This would also violate a requirement specifically agreed by the wg with a rather weak technical case for doing so. Hopefully this can help closing this discussion. Best regards, /Ghyslain --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Dec 15 07:39:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05542 for ; Mon, 15 Dec 2003 07:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVs06-0001H8-4O for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 07:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCd2o0004896 for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 07:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVs05-0001Gt-UG for rohc-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:39: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 HAA05527 for ; Mon, 15 Dec 2003 07:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVs05-0003QO-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 07:39:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVs04-0003QL-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 07:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVs04-0001Fd-Ow; Mon, 15 Dec 2003 07:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrzA-0001A0-8f for rohc@optimus.ietf.org; Mon, 15 Dec 2003 07:38: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 HAA05494 for ; Mon, 15 Dec 2003 07:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVrz9-0003Pf-00 for rohc@ietf.org; Mon, 15 Dec 2003 07:38:03 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AVrz8-0003Pa-00 for rohc@ietf.org; Mon, 15 Dec 2003 07:38:02 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBFCc18K006152; Mon, 15 Dec 2003 13:38:02 +0100 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW91MD56; Mon, 15 Dec 2003 13:39:01 +0100 Received: by lms001.lu.erisoft.se id NAA16962; Mon, 15 Dec 2003 13:38:01 +0100 (MET) Message-ID: <3FDDABDD.9EEF6CF0@ericsson.com> Date: Mon, 15 Dec 2003 13:41:01 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zhigang.c.liu@nokia.com CC: Yousuf.Saifullah@nokia.com, rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <7B5AF06E216CB74DA8A5960A3181B5B808E91E@ajebe001.americas.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id hBFCc18K006152 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 See included comments. Best regards, /Ghyslain zhigang.c.liu@nokia.com wrote: >=20 > One scenario is the mobile router case. I think Yousuf already mentione= d > this a few times. But for some reason, it seems it has been ignored. >=20 > The scenario is quite simple: a subnet behind a router which connects > to the Internet via a bandwidth-limited link. For example, a PAN (perso= nal > area network) or a subnet on a train, plane, etc. ROHC can reside in > the router to compress headers that are sent over the link. >=20 > There is already a related WG called nemo: > http://www.ietf.org/html.charters/nemo-charter.html. You can find more > details there. But above few words should already give you a good pictu= re. From what I understand, only the first connection to each device could potentially see some benefit in such scenario.=20 =20 > Even for case of last-link header compression, IP address compression > is also useful if the endpoint can refer to a context that contains > at least IP address prefix. It is true that the ROHC channels are In case of last-link header compression, you _will_ get exact-match or no match. > different between different endpoints and the HC entity on the > network side. So this is a small technical issue on how to refer to > a context from another channel. But, one simple solution could be to > use a common context that is independent of channels. The above seems rather flawed when considering last-link header compression. I fail to relate the above text to the concept of ROHC channels (CIDs, channel negotiation, etc). =20 > BR, > Zhigang >=20 --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Dec 15 07:40:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05600 for ; Mon, 15 Dec 2003 07:40:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVs19-0001LC-CU for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 07:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFCe6CK005143 for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 07:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVs17-0001Kn-MV for rohc-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:40: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 HAA05560 for ; Mon, 15 Dec 2003 07:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVs16-0003R1-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 07:40:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVs16-0003Qx-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 07:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVs15-0001JL-NI; Mon, 15 Dec 2003 07:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVs0Q-0001HH-EI for rohc@optimus.ietf.org; Mon, 15 Dec 2003 07:39: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 HAA05534 for ; Mon, 15 Dec 2003 07:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVs0P-0003Qd-00 for rohc@ietf.org; Mon, 15 Dec 2003 07:39:21 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AVs0O-0003Qa-00 for rohc@ietf.org; Mon, 15 Dec 2003 07:39:21 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBFCdK8K006337; Mon, 15 Dec 2003 13:39:20 +0100 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7XMKQH; Mon, 15 Dec 2003 13:39:20 +0100 Received: by lms001.lu.erisoft.se id NAA16990; Mon, 15 Dec 2003 13:39:22 +0100 (MET) Message-ID: <3FDDAC2D.9686D458@ericsson.com> Date: Mon, 15 Dec 2003 13:42:21 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yousuf.Saifullah@nokia.com CC: rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <025E7DD4182874489CC2F61EE0FA19CE0139893F@daebe004.americas.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id hBFCdK8K006337 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 See more included comments Best regards, /Ghyslain Yousuf.Saifullah@nokia.com wrote: >=20 > Hi Lars-Erik and Fredrick, >=20 > Please see my response below. >=20 > > -----Original Message----- > > From: ext Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson@ericsson.com] > > Sent: Friday, December 12, 2003 3:05 AM > > To: Saifullah Yousuf (NRC/Dallas) > > Cc: rohc@ietf.org > > Subject: RE: [rohc] IP Address Compression for Context Replication > > > > > > Yousuf, > > > > Please explain in more detail the scenarios you are addressing, > > so that we can better understand the reason you think this is > > important. At the moment, people do not seem to think this is > > really needed, but we should make sure we do not decide before > > we have all understood the arguments (first then can we have an > > opinion on how to proceed). > > > > Thanks! > > /L-E > > >=20 > Zhigang has explained the mobile router, which I think is important > for consideration. I will explain some other. >=20 > Compressed link between two gateways: e.g. in cellular network Base > Station Controller and Base Transceiver Station could have a satellite > link. In this case we can use IP address compression between multiple > hosts. How common a case is a statellite link between BSC and Node B??? =20 > A group of devices, e.g. bluetooth devices, forming personal area > network, which are connected through a device, e.g. phone, to an > external network. It is possible the devices will have similar IP > addresses, so they can be routed through phone. If the compressed link = > is between This is not header compression based on the behavior of header fields, but based on assumptions that are hardly to be expected. =20 > The above scenarios should help in understanding the need for IP > address compression. (...) =20 > The specs should be designed to efficiently support foreseeable > scenarios also, not just the existing ones. I feel we are chasing ghosts here. My impression is that this is a solution looking for a problem. See also further comments later in this mail about why I have this impression.=20 =20 > > -----Original Message----- > > From: ext Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson@ericsson.com] > > Sent: Friday, December 12, 2003 3:11 AM > > To: Saifullah Yousuf (NRC/Dallas) > > Cc: rohc@ietf.org > > Subject: RE: [rohc] IP Address Compression for Context Replication > > > > > > > I don't see, how we can have multiple replicate_formats. > > > > Of course there can be different replicate formats. > > > > > Considering that any optional feature can only be implemented > > > by different profile. If we define different formats, then > > > how we are going to tell compressor/decompressor which format > > > to use. > > > > The indicator bits gives the format. I do not really understand > > what you mean by "optional feature can only be implemented by > > different profile". That is the case if you have a feature that > > both compressor and decompressor must be allowed to choose > > whether to support or not, but otherwise you can different > > kinds of formats using different compression methoods. > > > > /L-E > > > I may have misunderstood. Where is that "indicator bits"? I don't see > in rohc-tcp-05. Are you talking about the "discriminator" field? >=20 > OK! There are two cases for making a feature optional. One mentioned > by you in the above para. The other case is that we make both > compressor and decompressor use another replicate_format for the IP > Address Compression. In this way, even if the replicate_format_0 does > not have any space for the 2 additional bits of the src/dest IP > address discriminator, the new replicate format would have. The > advantage is that in the cases where IP address compression is not > needed, there won't be any cost for carrying these two additonal bits. > In the cases, where IP address compression is used, it will save much > more than 2 bits to justify the cost. We can define replicate_format_1 > for IP address compression, if there is no spare bit available in > replicate_format_0 (which still need to be seen). See my previous mail under "Optional features". =20 > The IPR status is changed to "non-assertive", as I mentioned in an > earlier email. Therefore, implementation on both compressor and > decompressor should not be a concern. Please consider this point also. I am no lawyer, but an IPR is an IPR - and this issue still concerns me. See also my previous mail under "ROHC-TCP/CR Requirements" =20 > Thanks, > Yousuf >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Dec 15 13:30:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19297 for ; Mon, 15 Dec 2003 13:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxTs-0008K2-Me for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 13:30:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFIU8GG031984 for rohc-archive@odin.ietf.org; Mon, 15 Dec 2003 13:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxTr-0008Jn-9E for rohc-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 13:30: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 NAA19289 for ; Mon, 15 Dec 2003 13:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVxTp-00027Q-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 13:30:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVxTo-00027N-00 for rohc-web-archive@ietf.org; Mon, 15 Dec 2003 13: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 1AVxTp-0008JS-2A; Mon, 15 Dec 2003 13: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 1AVxTH-0008Ik-FQ for rohc@optimus.ietf.org; Mon, 15 Dec 2003 13:29:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19283 for ; Mon, 15 Dec 2003 13:29:27 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVxTF-000270-00 for rohc@ietf.org; Mon, 15 Dec 2003 13:29:29 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AVxTE-00026x-00 for rohc@ietf.org; Mon, 15 Dec 2003 13:29:28 -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 hBFITRH01859 for ; Mon, 15 Dec 2003 20:29:28 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 20:29:27 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 10:29:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Mon, 15 Dec 2003 12:29:23 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398942@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcPDCJDImno/zf6zTlSWxvim8wRDoAAGfW4w To: , X-OriginalArrivalTime: 15 Dec 2003 18:29:23.0719 (UTC) FILETIME=[5CFDB970:01C3C339] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ghyslain, Thank you for your attempt for bringing the discussion to a closing. I = think you have missed some recent discussion about using byte-wise = matched length, using replicate_format_1 for the structure containing IP = address compression, IPR status change to non-assertive, etc. I am = attempting to fill those points in this summary, so it could reflect = latest thoughts and analysis. This would help in bringing closure.=20 I also hope that other folks in this email list participate. Considering = also the points that were missed and now I have added in this summary. Best Regards, Yousuf > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Ghyslain Pelletier > Sent: Monday, December 15, 2003 6:41 AM > To: rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi all, >=20 > I went through the mail exchanges regarding this topic and here are my > opinions and conclusions. Hopefully this can help bringing the > discussion to a closing. >=20 > PREFIX-Match > ------------ > I agree that a prefix match can occur in some _specific_ cases. >=20 They are not some unrealistic and specific cases. I am answering your = comments (sent in your last two emails on this thread) on those cases = below: For mobile router case you wrote: "From what I understand, only the first connection to each device could potentially see some benefit in such scenario." The above is not correct. For every new connection, the IP address = compression could save header. =20 For BSC to BTS case you wrote: "How common a case is a statellite link between BSC and Node B???" The satellite link in the infra-structure of cellular is quite common. I = wish I had statistics in front of me to tell you in terms of percentage. = I know it is not insignificant. For a group of devices case you wrote: "This is not header compression based on the behavior of header fields, but based on assumptions that are hardly to be expected."=20 I don't think it is hard to expect this case. As I have mentioned = earlier, that we should define a protocol considering foreseeble future = in mind also. Not what we though two years ago as part of TCP field = behavior.=20 You can call it chasing ghosts. But, if we don't do that, whatever we = develop, it would become deficient and archaic soon. I am assuming that = by chasing gosts you mean unrealistic cases. Now we really first time = started to discuss these cases, could you please elaborate why you think = the above cases are unrealistic. > However, this is not a typical scenario and thus my feeling is that > there is no strong motivation to "optimize" ROHC-CR for this > (furthermore with consideration that CR itself is already an > optimization of the existing context initialization procedure). > The IP address compression is part of CR. It is also an optimization of = the existing context initialization procedure, just like compression of = exact match IP address, partial match TCP ports, etc. =20 > From the discussions, it seems that in the case of: > - IPv4 with either HTTP1.0 or HTTP1.1, it has been agreed that there=20 > would be no significant gain to include IP address compression; > - IPv6 with HTTP1.0 (multiple TCP connections), the potential=20 > gain would=20 > be very small, if any; > - IPv6 with HTTP1.1 (persistent TCP connection), there could be some=20 > gain - however in such case we are talking about the=20 > initialization of=20 > a single connection, and the 2-3 first packets (IR-CR). However the=20 > (lack of) applicability of IP address compression (see a=20 > later point=20 > in this mail) makes this potential gain negligible in my opinion. > =20 I think this is where you have missed most of the latest discussion. You = are only considering analysis sent by Kristofer, without including the = follow-up analysis and development. The following are the possible = cases now: Case-1: Single Host ; no impact, eplicate_format_0 will be used in this = case. The discriminator will indicate a structure without IP address = compression. There will be *no additional cost* for single host due to = ip_src/dest_addr.discriminator bits.=20 Case-2: Multiple Hosts; the discriminator will indicate a structure with = IP address compression, e.g. replicate_format_1 as I proposed in this = email = (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01897.h= tml). There will always be saving if a prefix match is found. A host = uses another hosts base context for IP address replication. For "m" new = connection, the saving will be m*(x-matched_len). With half as prefix = match. For IPv6, saving is m*60 bits; and for IPv4 saving is m*14 bits. = Pick a value of m, if what I have mentiond sounds (...) :). Also, I have = chosen byte-wise matched-len as mentioned in this email = (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01884.h= tml) > Therefore, before even considering how many bits we could save _when_ > this would occur, I am much more interested in knowing how frequently > PREFIX-matching can *realistically* occur. My opinion is that=20 > this is a > very marginal case. >=20 I have given the "realistic" cases above and before. As I have mentioned = above there is significant saving, without causing any cost to the 1 = host 1 server case. > SUFFIX-Match > ------------ > Zhigang.Liu@nokia.com wrote: > > I honestly don't know how often "suffix match" will occur, > > but think it's something useful to plan in protocol.=20 >=20 > I strongly doubt that a suffix match (e.g. part or all of the=20 > interface > ID) will occur in any scenario, other than due to pure coincidence. I > don't think we should design compression on such basis. >=20 As mentioned earlier. This was to make the procedure complete. We can = drop this. > EXACT-match > ----------- > I believe that this will be the most common scenario for=20 > replicating one > or both IP addresses. This is the scenario addressed by ROHC-CR. >=20 This is answered above. > Overhead > -------- > Some discriminators in the current IR-CR packets are currently longer > than necessary. This is in order to make the packet formats > byte-aligned. As the packet formats will soon be updated, there is no > guarantee that these bits will still be padding bits. This is thus not > an argument for adding IP address compression if the gain is not worth > it. > The IP address compression can be added without utilizing any pad and = cost of additional bits. I have mentioned this above with = repilcate_format_1. On a separate note, instead of sending some null bits better utilize = them for compression. I don't see any disagreement on this point. =20 > Gains > ----- > Yousuf.Saifullah@nokia.com wrote: > > We are totally ignoring another dimension of multiple hosts. > > In your equations we are only comparing n flows between 1 > > host and 1 server. If we have m multiple hosts in the system > > with compressible IP addresses. The saving will be 55*m bits > > for HTTP 1.1./IPv6. The theoretical value of m could be 2^64, > > but we can reasonably pick a value in multiples of tens of > > thousands. Let's say if we pick, 10,000. >=20 > has been a working group > document since March 2002. This is where the type of field behavior to > be addressed by TCP header compression has been discussed=20 > extensively.=20 >=20 > Section 6.5 specifically and clearly states that for short-lived flows > (i.e. the problem space for context replication), what is to be > considered is multiple TCP connections between the same pair of hosts. > So it is no surprise that this is the focus of ROHC-CR. >=20 > The case of "multiple hosts", would it be of any relevance at=20 > all, must > be discussed and agreed by the working group before we can consider it > an argument and so far I cannot see a strong case for it.=20 >=20 I see that ROHC-TCP and ROHC-CR drafts are under discussion. I don't = think any principle is violated by bringing up "multiple hosts". The = "multiple hosts" are valid scenarios, they will become more and more = common in near future, and doesn't cost you any bit in the header. I am = asking WG to not limit the solutions based on something we thought two = years ago, otherwise the solution would be deficient. It is not too late = do discuss the CR and TCP-CR. Any comment on this. BTW! The above = mentioned field behavior draft has expired.=20 =20 > > This would give a saving of 550,000 bits. >=20 > (...).=20 >=20 > Yousuf.Saifullah@nokia.com wrote: > > My point is that multiple host scenario is not uncommon to > > ignore. We should not limit the HC in the way you mentioned > > below. Moreover, the decision should be made based on cost > > vs. gain analysis. Again over here also we should not limit > > to HTTP 1.0 and IPv4. >=20 > Not including IP Address compression does not limit the HC in any way. > Please keep some context regarding the very limited applicability of > this proposal. IPv4 or IPv6 flows using either HTTP1.0 or HTTP1.1 can > still use context replication efficiently in the most expected cases. > Regarding cost vs. gain analysis - I agree! - and see also my next > comment on applicability and the last section of this mail where I add > "based on agreed requirements" as well... >=20 > Applicability/Scenarios > ----------------------- > Zhigang.Liu@nokia.com wrote: > > This brings another simple example: HTTP 1.1 proxy server, > > regardless if the origin server supports HTTP 1.1. A proxy > > server is quite typical configuration for a subnet. >=20 > I am quite confused here - isn't this also speaking in favor of > EXACT-match of the IP address as the most commonly expected scenario, > thus defeating the argument in itself? >=20 I think the confusion is you are only considering proxy server address. = Zhigang meant hosts addresses. > Zhigang.Liu@nokia.com wrote: > > First, I don't think n=3D50 (i.e. 50 simultaneous TCP connections) > > is realistic.=20 > > > > Second, the whole purpose or usefulness of TCP/IP HC is to > > reduce header overhead. Then, why would a client open many TCP > > connections to the same server and thus introduce extra header > > overhead/context, instead of using one persistant connection? > > It would look to me like creating problems and then solving it. > > It doen't make sense to me. >=20 > I agree! It is much smarter to use persistent connections. When doing > so, the number of new contexts to be initialized is less, thus much > fewer IR-CR would be sent and thus optimizing the cases where=20 > n=3D1 is of > little significance. In my opinion this means that the=20 > applicability of > IP Address compression is now even less motivated. > I think the above summary is incorrect. The applicability of IP address = compression is significant. Host-m can use IP address of Host-(m-1). The = current CR only allows Host-m to use IP address of itself. The IP = address compression is allowing it to use this plus context of = Host-(m-1). If there are "m" hosts, their IP address can be compressed = for every attempt of a new connection.=20 n=3D1 doesn't mean less, it only mean there is only one simultaneous TCP = connection between 1 host and 1 server. > Zhigang.Liu@nokia.com wrote: > > I don't know what is the current distribution between HTTP > > 1.0 and 1.1. But based on my knowledge, HTTP 1.1 used more > > and more to optimize performance. And for the simple reasons > > I gave above, it doesn't make sense to me to implement TCP/IP > > HC without eliminating the root of problems: too many TCP > > connections incurred by HTTP 1.0. >=20 > I think that it makes more sense for ROHC-CR to be particularly > well-suited for when that specific "problem" is occurring.=20 > And the most > commonly expected case is still when EXACT-match of the IP address > occurs anyway. >=20 > Zhigang.Liu@nokia.com wrote: > > As to IPv6 vs v4, my guess is that IPv4 will stay for > > sometime. But IPv6 will pick up, at least that is what I > > heard here in IETF and some other standardization > > orgonaizations. Regardless of what is current situaiton, > > a viable TCP/IP HC protocol should have a good handle of > > IPv6. As to IPv4, IP address compression still brings > > benifigs, though small. >=20 > I believe ROHC-TCP is viable by itself. ROHC-CR is an optimization for > ROHC-TCP that is also applicable to other profiles, and it is > particularly welcome for the TCP profile. Context replication targets > the initialization procedure, so keep in mind that we are=20 > talking about > 2-3 initial packets in most cases, not an optimization of the entire > compressed flow. Therefore I agree with you - IP address compression > bring only small benefits - and I will conclude also that this is not > often applicable and when so, only for a small number of=20 > packets within > the header compressed flow. >=20 Your agreement doesn't concur with what Zhigang said. There is a = significant benefit for IPv6, and he separted his v4 comment from v6. > Finally, I must say that I fail to understand from the proponents of > this solution a clear, realistic and useful scenario with a=20 > significant > gain. >=20 This has already been answered. > Optional features > ----------------- > Yousuf.Saifullah@nokia.com wrote: > > I don't see, how we can have multiple replicate_formats. Considering > > that any optional feature can only be implemented by different > > profile. If we define different formats, then how we are going to >=20 > Defining different formats and defining which ones are used is not a > problem - multiple packet formats must however all be supported by at > least the decompressor, therefore "multiple packet formats" is no > equivalent to "optional feature". >=20 > For a feature to be optional, it must be possible for a=20 > decompressor not > to implement it without possibility for the compressor to use the > feature, thus implying some form of beforehand negotiation=20 > (which could > take the form of the definition of different profiles, one supporting > the feature - the other not). >=20 I agree with you. Let's support "multiple packet formats". = replicate_format_1 with the IP address compression. This has already = been discussed earlier in this email. Everyone can implement "IP Address = Compression", because the status of IPR has changed(please see my = another comment below). So we don't need to implement this as "optional = feature". > ROHC-TCP/CR requirements > ------------------------ > Finally, and certainly not least, I'd like to remind that a=20 > requirement > has been explicitly _stated_, _motivated_ and *agreed* by the working > group in terms of IPRs with relation to ROHC-TCP and ROHC-CR, from > draft-ietf-rohc-tcp-requirements-06.txt - section 2.5 -=20 > "Requirements on > ROHC TCP/IP Header Compression". >=20 > (I am copy-pasting it here for everyone's convenience) >=20 > http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-requir > ements-06.txt >=20 > 2.5. Intellectual Property Rights (IPR) >=20 > The ROHC WG must spend effort to achieve a high degree of > confidence that there is no IPR covering a final compression > solution for TCP. >=20 > Justification: Currently there is no TCP header compression > scheme available that can efficiently compress the packet headers > of modern TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill > this gap by providing a ROHC TCP scheme that is applicable in the > wide area Internet, not only over error-prone radio links. It > must thus attempt to be as future-proof as possible, and only > unencumbered solutions will be acceptable to the Internet at > large. >=20 > This section has been present since > from June 20, 2001, where it > was agreed and included by the WG. To not meet it requires a > particularly strong case, which is not true for IP address=20 > compression. > You may have missed the email, where I have announce the IPR status = change to non-assertive. The IPR status is "non-assertive". It means no = one will be barred from using this IPR and everyone can implement it. = Please tell me, how this conflicts with the above requirement. =20 =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 16 10:35:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17737 for ; Tue, 16 Dec 2003 10:35:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHDd-0004zw-Lo for rohc-archive@odin.ietf.org; Tue, 16 Dec 2003 10:34:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFYfNx019212 for rohc-archive@odin.ietf.org; Tue, 16 Dec 2003 10:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHDd-0004zn-GC for rohc-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17712 for ; Tue, 16 Dec 2003 10:34:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHDb-0004M5-00 for rohc-web-archive@ietf.org; Tue, 16 Dec 2003 10:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHDS-0004Ko-00 for rohc-web-archive@ietf.org; Tue, 16 Dec 2003 10:34:38 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHDS-0004Jr-00 for rohc-web-archive@ietf.org; Tue, 16 Dec 2003 10:34:30 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWH7Z-0002Hz-8k for rohc-web-archive@ietf.org; Tue, 16 Dec 2003 10:28:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWH7B-0004qK-6i; Tue, 16 Dec 2003 10:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWH6v-0004pT-HB for rohc@optimus.ietf.org; Tue, 16 Dec 2003 10:27: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 KAA17391 for ; Tue, 16 Dec 2003 10:27:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWH6o-00045C-00 for rohc@ietf.org; Tue, 16 Dec 2003 10:27:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWH6J-00043x-00 for rohc@ietf.org; Tue, 16 Dec 2003 10:27:10 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AWH6I-00042F-00 for rohc@ietf.org; Tue, 16 Dec 2003 10:27: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 hBGFQeI2005013; Tue, 16 Dec 2003 16:26:40 +0100 (MET) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAP90PAG; Tue, 16 Dec 2003 16:26:40 +0100 Received: by lms001.lu.erisoft.se id QAA09426; Tue, 16 Dec 2003 16:26:42 +0100 (MET) Message-ID: <3FDF24E6.D98378A0@ericsson.com> Date: Tue, 16 Dec 2003 16:29:42 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yousuf.Saifullah@nokia.com, rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <025E7DD4182874489CC2F61EE0FA19CE01398942@daebe004.americas.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross-ext.wise.edt.ericsson.se id hBGFQeI2005013 Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, Actually, as the editor for both impacted documents I have been following this thread rather closely and I do not feel that I have missed any of the discussions or arguments when writing my previous mail (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01899.h= tml). I am simply trying to filter out statements without substance to bring up the agreements from my understooding of the list discussion. I guess I should furhter clarify my previous email regarding IP Address Compression (IP/AC). I'd invite anyone who's participated to that discussion so far to validate or invalidate the following summary, in order to help us move on with some form of consensus. My feeling is that the following agreements have been roughly reached on this mailing list regarding IP/AC: Technical aspects ----------------- T1) SUFFIX-Match is unrealistic (out); T2) PREFIX-Match is not possible for last-link context replication. This is because the last link means that the compressor/decompressor is=20 co-located with the IP endpoint and will not be routing packets=20 to/from any subnet; T3) ROHC-CR has been originally motivated for cases when at least one IP address was the same - this being the trigger for replication. Given this, it makes less sense to attempt to compress differently IP address; T4) Defining a separate packet format for a "feature" does not make the "feature" optional - decompressor is still forced to implement it=20 unless some form of negotiation is used or separate profiles; T5) Any potentially noticeable gain would only occur with IPv6/HTTP1.1=20 (persistent TCP connection), not with IPv4 or HTTP1.0. Persistent connections are probably longer-lived and, therefore, the impact of any kind of replication is lower, making IP/AC even less=20 significant with respect to IPv6/HTTP1.1; T6) Any potential gain with IP/AC is not of major significance, also=20 considering that IR-CR is already an optimization of the=20 initialization procedure only (see also NT3). Non-technical aspects --------------------- NT1) Motivations for the "field behavior" addressed by ROHC-TCP/CR HC=20 has been extensively discussed and agreed. Addressing a different=20 type of behavior must be properly motivated - just like behaviors=20 currently addressed. NT2) The fact that some bits are currently used for byte-alignment in=20 the TCP IR-CR packet formats is not a motivation for including=20 IP/AC; NT3) Applicability of IP/AC (mobile router and satellite links - i.e.=20 not last-link) is limited and not the most expected case; NT4) A requirement regarding IPRs was agreed by the wg for the TCP=20 solution. I understand the meaning of "non-assertive" (as read from http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft -saifullah-rohc-ip-addr-comp-context-replicat.txt), but the IPR statement still mentions some limitations as to the=20 non-assertivness of the IPR being only valid if other companies do=20 not assert ANY patents against Nokia (even patents not related to ROHC); NT5) The scenarios for motivating the occurence of PREFIX-Match are too=20 weak for including IP/AC in the ROHC-TCP/CR solution; NT6) Points T6) and NT5) are too weak to make IP/AC a core functionality of ROHC-TCP/CR with respect to violating NT4). Best regards, /Ghyslain Yousuf.Saifullah@nokia.com wrote: >=20 > Hi Ghyslain, > Thank you for your attempt for bringing the discussion to a closing. > I think you have missed some recent discussion about using byte-wise > matched length, using replicate_format_1 for the structure containing > IP address compression, IPR status change to non-assertive, etc. I am > attempting to fill those points in this summary, so it could reflect > latest thoughts and analysis. This would help in bringing closure. >=20 > I also hope that other folks in this email list participate. > Considering also the points that were missed and now I have added in > this summary. >=20 > Best Regards, > Yousuf >=20 > > -----Original Message----- Can be found at: http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01899.ht= ml --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 16 19:36:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16426 for ; Tue, 16 Dec 2003 19:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWPfZ-0007KK-Pr for rohc-archive@odin.ietf.org; Tue, 16 Dec 2003 19:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBH0a5Ve028158 for rohc-archive@odin.ietf.org; Tue, 16 Dec 2003 19:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWPfZ-0007K5-Hd for rohc-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 19:36: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 TAA16420 for ; Tue, 16 Dec 2003 19:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWPfX-0003ze-00 for rohc-web-archive@ietf.org; Tue, 16 Dec 2003 19:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWPfU-0003zI-00 for rohc-web-archive@ietf.org; Tue, 16 Dec 2003 19:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWPfU-0003zF-00 for rohc-web-archive@ietf.org; Tue, 16 Dec 2003 19:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWPfV-0007JZ-DG; Tue, 16 Dec 2003 19: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 1AWPfM-0007Iw-Mx for rohc@optimus.ietf.org; Tue, 16 Dec 2003 19:35:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16407 for ; Tue, 16 Dec 2003 19:35:48 -0500 (EST) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWPfK-0003yr-00 for rohc@ietf.org; Tue, 16 Dec 2003 19:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWPfJ-0003yk-00 for rohc@ietf.org; Tue, 16 Dec 2003 19:35:50 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWPfI-0003yh-00 for rohc@ietf.org; Tue, 16 Dec 2003 19:35:48 -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 hBH0Zm729890 for ; Wed, 17 Dec 2003 02:35:48 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Dec 2003 02:35:47 +0200 Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 16:35:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] IP Address Compression for Context Replication Date: Tue, 16 Dec 2003 18:34:59 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0121DE28@daebe004.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcPD6RcOSRrzNdUHSFyXZ2eoqj1osQAK3KOA To: , X-OriginalArrivalTime: 17 Dec 2003 00:35:00.0356 (UTC) FILETIME=[9AA8A440:01C3C435] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ghyslain, I am afraid I have to repeat myself a lot in this email. I don't think = the summarization are done correctly in your email. Only partial views = are presented without considering what Zhigang and I have answered for = those views. Even my last email was ignored, which pointed to those = earlier discussion. Please tell me why those statements are without = substance. Please don't just ignore them, give some argument. Please = don't just apply your filter without telling the WG the contents of your = filter :) This is the main point, which you are missing. IP/AC can be added = without costing a single bit in replicate_format_0. This can be done by = defining replicate_format_1. The "discriminator" field is defined for = this purpose and will be used to indicate different formats. The IPR = status is "non-assertive", and the IP/AC doesn't need to be optional and = it can be implemented as part of CR by any body. If you have a single = host (last-link), only replicate_format_0 will be used and there is no = overhead. Please see my specific responses below to correctly reflect = the agreement/summary.=20 Best Regards, Yousuf > -----Original Message----- > From: ext Ghyslain Pelletier [mailto:Ghyslain.Pelletier@ericsson.com] > Sent: Tuesday, December 16, 2003 9:30 AM > To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication >=20 >=20 > Hi all, >=20 > Actually, as the editor for both impacted documents I have been > following this thread rather closely and I do not feel that I have > missed any of the discussions or arguments when writing my=20 > previous mail > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > /msg01899.html). > I am simply trying to filter out statements without substance to bring > up the agreements from my understooding of the list discussion. >=20 > I guess I should furhter clarify my previous email regarding=20 > IP Address > Compression (IP/AC). I'd invite anyone who's participated to that > discussion so far to validate or invalidate the following summary, in > order to help us move on with some form of consensus. >=20 > My feeling is that the following agreements have been roughly=20 > reached on > this mailing list regarding IP/AC: >=20 > Technical aspects > ----------------- > T1) SUFFIX-Match is unrealistic (out); > T2) PREFIX-Match is not possible for last-link context=20 > replication. This > is because the last link means that the=20 > compressor/decompressor is=20 > co-located with the IP endpoint and will not be routing packets=20 > to/from any subnet Prefix match is quite possible in other viable scenarios. I have = mentioned them before. Why we have to limit our solution to the = last-link CR, with one host at the end. We should not limit our = solutions based on something we thought two years ago, otherwise the = solution would be deficient. We may end up revising the draft soon. = Please add this point. > T3) ROHC-CR has been originally motivated for cases when at least one > IP address was the same - this being the trigger for replication. > Given this, it makes less sense to attempt to compress differently > IP address; We should try to develop a good solution, considering our latest = knowledge and foresight. Why we have to limit ourselves to what we = thought originally. Isn't ROHC-CR under development? Make ROHC-CR = applicable for multiple hosts also.=20 > T4) Defining a separate packet format for a "feature" does=20 > not make the > "feature" optional - decompressor is still forced to implement it=20 > unless some form of negotiation is used or separate profiles; This tells me that you have missed some emails on this thread. Please = read my emails on this topic. I am not asking you to make the feature = optional at all. Implement IP Address Compression on both ends as = mandatory feature. The IPR status is changed to "non-assertive", = everyone in the world can implement this IPR. We will use separate = packet formats to save the cost in terms of bit. > T5) Any potentially noticeable gain would only occur with=20 > IPv6/HTTP1.1=20 > (persistent TCP connection), not with IPv4 or HTTP1.0. Persistent > connections are probably longer-lived and, therefore, the=20 > impact of > any kind of replication is lower, making IP/AC even less=20 > significant with respect to IPv6/HTTP1.1; This is incorrect I have challenged it in my last email, but you didn't = replied. Please do not repeat the above without commenting on the text = below.=20 If I use replicate_format_0 in the cases of 1 host and 1 server, and I = use replicate_format_1 with additional 2 bits needed for the = ip_src/dst_addr.discriminator. The gain is with IPv4 and HTTP 1.0 also. = Let me explain it again. You are only considering analysis sent by = Kristofer, without including the follow-up analysis and development. = Kristofer's analysis considers saving in multiple connections between 1 = host and 1 server, considering the cost of the above 2 additional bits. = He assumed that we have only one structure, replicate_format_0 and we = have to fit this IP addresss compression in the same structure. Later, = we realized that we can use two separate structures using = "discriminator" bits. If we use separate structures, we don't have = additional cost of 2 bits for IP/AC. When we don't have IP/AC, e.g. = multiple connections between 1 host and 1 server, we will use = replicate_format_0. When we have IP/AC, e.g. multiple hosts, we will use = replicate_format_1. Thus, Kristofer's analysis for cost becomes invalid. = I think the above is an important point which is being missed. The following are the possible cases now: Case-1: Single Host ; no impact, replicate_format_0 will be used in this = case. The discriminator will indicate a structure without IP address = compression. There will be *no additional cost* for single host due to = ip_src/dest_addr.discriminator bits. No change for IPv4/v6/HTTP1.0/1.1, = everything stays as it is now in the current ROHC-CR and ROHC-TCP draft. Case-2: Multiple Hosts; the discriminator will indicate a structure with = IP address compression, e.g. replicate_format_1 as I proposed in this = email = (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01897.h= tml). There will always be saving if a prefix match is found. A host = uses another hosts base context for IP address replication. For "m" new = connection, the saving will be m*(x-matched_len). With half as prefix = match. For IPv6, saving is m*60 bits; and for IPv4 saving is m*14 bits. = Pick a value of m, if what I have mentiond sounds (...) :). Also, I have = chosen byte-wise matched-len as mentioned in this email = (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01884.h= tml) > T6) Any potential gain with IP/AC is not of major significance, also=20 > considering that IR-CR is already an optimization of the=20 > initialization procedure only (see also NT3). My above comments nullifies this conclusion. If you don't agree, please = tell me why not. >=20 > Non-technical aspects > --------------------- > NT1) Motivations for the "field behavior" addressed by ROHC-TCP/CR HC=20 > has been extensively discussed and agreed. Addressing a=20 > different=20 > type of behavior must be properly motivated - just like=20 > behaviors=20 > currently addressed. Please see my comment under NT3. > NT2) The fact that some bits are currently used for byte-alignment in=20 > the TCP IR-CR packet formats is not a motivation for including=20 > IP/AC; IP/AC is not asking to use any byte-alignment bits. Again, you are = missing the point and earlier emails from me. I have repeated this = above. Please let me know what is not clear in my statements.=20 > NT3) Applicability of IP/AC (mobile router and satellite links - i.e.=20 > not last-link) is limited and not the most expected case; We should not limit our solution for only "one" case, which we thought = two years ago during the "field behavior" discussion. We have missed = some case at that time, and now we have chance to include them. Why not = broaden the solution to these likely cases? Especially, when doing so is = not costing a bit for the previously thought case. In fact, it is saving = more bits and will make CR more efficient.=20 I am not suggesting IP/AC, when the ROHC-CR or ROHC-TCP are frozen for = further changes. I am suggesting them while we are discussing and = inviting comments on these drafts. I think any hesitation based on our = previously set mind should be questionable. > NT4) A requirement regarding IPRs was agreed by the wg for the TCP=20 > solution. I understand the meaning of "non-assertive" > (as read from=20 > http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft > -saifullah-rohc-ip-addr-comp-context-replicat.txt), > but the IPR statement still mentions some limitations as to the=20 > non-assertivness of the IPR being only valid if other=20 > companies do=20 > not assert ANY patents against Nokia (even patents not related to > ROHC); The text "(even patents not related to ROHC)" is not on the IPR = web-site. It was added by you. I am copying the whole text below for the = benefit of others:=20 "This is an update to the earlier Nokia IPR disclosure to=20 the subject draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt=20 (submitted on 2.12.2003). This is to advise the IETF that Nokia has pending unpublished=20 patent application "Compressing header data" that may relate to the Internet Draft=20 submission: IP Address Compression in Context Replication=20 (draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt). Regarding this Internet Draft submission=20 draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt,=20 to the extent this submission is included into final IETF=20 standard spesification, Nokia agrees not to assert those claims in Nokia patents that apply to this=20 submission and are technically necessary to implement the IETF=20 standard spesification against any other party in respect of its=20 implementation of the specification, provided that the party relying=20 on this commitment does not assert its patents against Nokia." I am not a legal expert, but the above statement read perfectly neutral = to me. I would encourage other mailing list participants also to explain = to me why the above statement is not neutral. =20 > NT5) The scenarios for motivating the occurence of=20 > PREFIX-Match are too=20 > weak for including IP/AC in the ROHC-TCP/CR solution; > NT6) Points T6) and NT5) are too weak to make IP/AC a core > functionality of ROHC-TCP/CR with respect to violating NT4). >=20 Please reconsider NT5 and NT6 based on my above comments. > Best regards, >=20 > /Ghyslain >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 17 02:11:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09355 for ; Wed, 17 Dec 2003 02:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWVps-0004A1-Ek for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 02:11:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBH7B8nF015993 for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 02:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWVpq-00049s-NZ for rohc-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 02:11: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 CAA08791 for ; Wed, 17 Dec 2003 02:11:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWVpn-0005Yn-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 02:11:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWVpm-0005Yf-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 02:11:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWVpl-0005Yc-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 02:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWVpm-00049G-Sj; Wed, 17 Dec 2003 02: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 1AWVox-00040M-DN for rohc@optimus.ietf.org; Wed, 17 Dec 2003 02:10: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 CAA07889 for ; Wed, 17 Dec 2003 02:10:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWVot-0005YJ-00 for rohc@ietf.org; Wed, 17 Dec 2003 02:10:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWVot-0005YC-00 for rohc@ietf.org; Wed, 17 Dec 2003 02:10:07 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 1AWVos-0005Y9-00 for rohc@ietf.org; Wed, 17 Dec 2003 02:10:06 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id hBH7A1qP006163 for ; Wed, 17 Dec 2003 15:10:01 +0800 (SGT) Received: from wolf ([192.168.152.169]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with SMTP id <0HQ100BHK2KUPC@mailhost.lit.org.sg> for rohc@ietf.org; Wed, 17 Dec 2003 15:10:06 +0800 (SGT) Date: Wed, 17 Dec 2003 15:10:06 +0800 From: Wang Haiguang To: rohc@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [rohc] A question about the context refreshment in ROHC U-mode Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, In the specification for the compressor state transition scheme (RFC3095 5.3.1.1.1 -- 5.3.1.1.3). I see the periodic context refreshment part refers to the IPHC (RFC 2507) 3.3.1-3.3.2, which contains the compression slow start scheme. Is the compression slow start scheme also used in ROHC at the beginning of a session? Or just sent out consectutive IR packets assume k and then the compressor transit to higher state, i.e. the SO state and send out packet with compressed headers. I find that compression slow start is also mentioned in the ROHC TCP draft. Best regards. Haiguang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 17 03:03:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27369 for ; Wed, 17 Dec 2003 03:03:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWWdn-0007ga-IU for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 03:02:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBH82hKC029538 for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 03:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWWdn-0007gL-8J for rohc-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 03:02:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27292 for ; Wed, 17 Dec 2003 03:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWWdj-00010Z-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 03:02:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWWdE-0000vZ-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 03:02:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWWdD-0000vV-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 03:02:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWWd8-0007bN-GS; Wed, 17 Dec 2003 03:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWWcb-0007ZB-GR for rohc@optimus.ietf.org; Wed, 17 Dec 2003 03:01: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 DAA27148 for ; Wed, 17 Dec 2003 03:01:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWWcW-0000o2-00 for rohc@ietf.org; Wed, 17 Dec 2003 03:01:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWWc9-0000k5-00 for rohc@ietf.org; Wed, 17 Dec 2003 03:01:23 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AWWc7-0000eb-00 for rohc@ietf.org; Wed, 17 Dec 2003 03:00:59 -0500 Received: from effnet.com ([192.168.101.51]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id hBH70EqP006358 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 17 Dec 2003 08:00:20 +0100 Message-ID: <3FE00D1B.2090407@effnet.com> Date: Wed, 17 Dec 2003 09:00:27 +0100 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication References: <025E7DD4182874489CC2F61EE0FA19CE0121DE28@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE0121DE28@daebe004.americas.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I'm not going into discussing every point due to lack of time, so I'm just going to provide my own conclusions of the discussion. I have to agree with Ghyslains summary of the discussion. I don't think the arguments for IP/AC have managed to convince people that this will save "enough" or that it will be "applicable enough". Apart from the authors IP/AC, I haven't really seen support for it. And, as Ghyslain points out, even if the IPR is non-assertive, there are specific conditions placed on it being non-assertive. Quote from the patent statement: >>> ...provided that the party relying on this commitment does not assert its >>> patents against Nokia. If it is "conditionally non-assertive", then it is not "non-assertive". Therefore I believe it is still "in violation of" the requirements set by the WG. I think this is reason enough for not adapting IP/AC. Just my 2 cents. Best regards, Kristofer Sandlund, Effnet AB Yousuf.Saifullah@nokia.com wrote: > Hi Ghyslain, > I am afraid I have to repeat myself a lot in this email. I don't think the summarization are done correctly in your email. Only partial views are presented without considering what Zhigang and I have answered for those views. Even my last email was ignored, which pointed to those earlier discussion. Please tell me why those statements are without substance. Please don't just ignore them, give some argument. Please don't just apply your filter without telling the WG the contents of your filter :) > > This is the main point, which you are missing. IP/AC can be added without costing a single bit in replicate_format_0. This can be done by defining replicate_format_1. The "discriminator" field is defined for this purpose and will be used to indicate different formats. The IPR status is "non-assertive", and the IP/AC doesn't need to be optional and it can be implemented as part of CR by any body. If you have a single host (last-link), only replicate_format_0 will be used and there is no overhead. Please see my specific responses below to correctly reflect the agreement/summary. > > Best Regards, > Yousuf > > >>-----Original Message----- >>From: ext Ghyslain Pelletier [mailto:Ghyslain.Pelletier@ericsson.com] >>Sent: Tuesday, December 16, 2003 9:30 AM >>To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org >>Subject: Re: [rohc] IP Address Compression for Context Replication >> >> >>Hi all, >> >>Actually, as the editor for both impacted documents I have been >>following this thread rather closely and I do not feel that I have >>missed any of the discussions or arguments when writing my >>previous mail >>(http://www1.ietf.org/mail-archive/working-groups/rohc/current >>/msg01899.html). >>I am simply trying to filter out statements without substance to bring >>up the agreements from my understooding of the list discussion. >> >>I guess I should furhter clarify my previous email regarding >>IP Address >>Compression (IP/AC). I'd invite anyone who's participated to that >>discussion so far to validate or invalidate the following summary, in >>order to help us move on with some form of consensus. >> >>My feeling is that the following agreements have been roughly >>reached on >>this mailing list regarding IP/AC: >> >>Technical aspects >>----------------- >>T1) SUFFIX-Match is unrealistic (out); >>T2) PREFIX-Match is not possible for last-link context >>replication. This >> is because the last link means that the >>compressor/decompressor is >> co-located with the IP endpoint and will not be routing packets >> to/from any subnet > > > Prefix match is quite possible in other viable scenarios. I have mentioned them before. Why we have to limit our solution to the last-link CR, with one host at the end. We should not limit our solutions based on something we thought two years ago, otherwise the solution would be deficient. We may end up revising the draft soon. Please add this point. > > >>T3) ROHC-CR has been originally motivated for cases when at least one >> IP address was the same - this being the trigger for replication. >> Given this, it makes less sense to attempt to compress differently >> IP address; > > > We should try to develop a good solution, considering our latest knowledge and foresight. Why we have to limit ourselves to what we thought originally. Isn't ROHC-CR under development? Make ROHC-CR applicable for multiple hosts also. > > >>T4) Defining a separate packet format for a "feature" does >>not make the >> "feature" optional - decompressor is still forced to implement it >> unless some form of negotiation is used or separate profiles; > > > This tells me that you have missed some emails on this thread. Please read my emails on this topic. I am not asking you to make the feature optional at all. Implement IP Address Compression on both ends as mandatory feature. The IPR status is changed to "non-assertive", everyone in the world can implement this IPR. We will use separate packet formats to save the cost in terms of bit. > > > >>T5) Any potentially noticeable gain would only occur with >>IPv6/HTTP1.1 >> (persistent TCP connection), not with IPv4 or HTTP1.0. Persistent >> connections are probably longer-lived and, therefore, the >>impact of >> any kind of replication is lower, making IP/AC even less >> significant with respect to IPv6/HTTP1.1; > > > This is incorrect I have challenged it in my last email, but you didn't replied. Please do not repeat the above without commenting on the text below. > > If I use replicate_format_0 in the cases of 1 host and 1 server, and I use replicate_format_1 with additional 2 bits needed for the ip_src/dst_addr.discriminator. The gain is with IPv4 and HTTP 1.0 also. Let me explain it again. You are only considering analysis sent by Kristofer, without including the follow-up analysis and development. Kristofer's analysis considers saving in multiple connections between 1 host and 1 server, considering the cost of the above 2 additional bits. He assumed that we have only one structure, replicate_format_0 and we have to fit this IP addresss compression in the same structure. Later, we realized that we can use two separate structures using "discriminator" bits. If we use separate structures, we don't have additional cost of 2 bits for IP/AC. When we don't have IP/AC, e.g. multiple connections between 1 host and 1 server, we will use replicate_format_0. When we have IP/AC, e.g. multiple hosts, we will use replicate_format_1. Thus, Kristof er's analysis for cost becomes invalid. > > I think the above is an important point which is being missed. > > The following are the possible cases now: > > Case-1: Single Host ; no impact, replicate_format_0 will be used in this case. The discriminator will indicate a structure without IP address compression. There will be *no additional cost* for single host due to ip_src/dest_addr.discriminator bits. No change for IPv4/v6/HTTP1.0/1.1, everything stays as it is now in the current ROHC-CR and ROHC-TCP draft. > > Case-2: Multiple Hosts; the discriminator will indicate a structure with IP address compression, e.g. replicate_format_1 as I proposed in this email (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01897.html). There will always be saving if a prefix match is found. A host uses another hosts base context for IP address replication. For "m" new connection, the saving will be m*(x-matched_len). With half as prefix match. For IPv6, saving is m*60 bits; and for IPv4 saving is m*14 bits. Pick a value of m, if what I have mentiond sounds (...) :). Also, I have chosen byte-wise matched-len as mentioned in this email (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01884.html) > > > >>T6) Any potential gain with IP/AC is not of major significance, also >> considering that IR-CR is already an optimization of the >> initialization procedure only (see also NT3). > > > My above comments nullifies this conclusion. If you don't agree, please tell me why not. > > >>Non-technical aspects >>--------------------- >>NT1) Motivations for the "field behavior" addressed by ROHC-TCP/CR HC >> has been extensively discussed and agreed. Addressing a >>different >> type of behavior must be properly motivated - just like >>behaviors >> currently addressed. > > > Please see my comment under NT3. > > >>NT2) The fact that some bits are currently used for byte-alignment in >> the TCP IR-CR packet formats is not a motivation for including >> IP/AC; > > > IP/AC is not asking to use any byte-alignment bits. Again, you are missing the point and earlier emails from me. I have repeated this above. Please let me know what is not clear in my statements. > > >>NT3) Applicability of IP/AC (mobile router and satellite links - i.e. >> not last-link) is limited and not the most expected case; > > > > We should not limit our solution for only "one" case, which we thought two years ago during the "field behavior" discussion. We have missed some case at that time, and now we have chance to include them. Why not broaden the solution to these likely cases? Especially, when doing so is not costing a bit for the previously thought case. In fact, it is saving more bits and will make CR more efficient. > > I am not suggesting IP/AC, when the ROHC-CR or ROHC-TCP are frozen for further changes. I am suggesting them while we are discussing and inviting comments on these drafts. I think any hesitation based on our previously set mind should be questionable. > > >>NT4) A requirement regarding IPRs was agreed by the wg for the TCP >> solution. I understand the meaning of "non-assertive" >> (as read from >>http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft >> -saifullah-rohc-ip-addr-comp-context-replicat.txt), >> but the IPR statement still mentions some limitations as to the >> non-assertivness of the IPR being only valid if other >>companies do >> not assert ANY patents against Nokia (even patents not related to >> ROHC); > > > The text "(even patents not related to ROHC)" is not on the IPR web-site. It was added by you. I am copying the whole text below for the benefit of others: > > "This is an update to the earlier Nokia IPR disclosure to > the subject draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt > (submitted on 2.12.2003). > > This is to advise the IETF that Nokia has pending unpublished > patent application > "Compressing header data" that may relate to the Internet Draft > submission: IP Address Compression in Context Replication > (draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt). > > Regarding this Internet Draft submission > draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt, > to the extent this submission is included into final IETF > standard spesification, Nokia agrees > not to assert those claims in Nokia patents that apply to this > submission and are technically necessary to implement the IETF > standard spesification against any other party in respect of its > implementation of the specification, provided that the party relying > on this commitment does not assert its patents against Nokia." > > I am not a legal expert, but the above statement read perfectly neutral to me. I would encourage other mailing list participants also to explain to me why the above statement is not neutral. > > > >>NT5) The scenarios for motivating the occurence of >>PREFIX-Match are too >> weak for including IP/AC in the ROHC-TCP/CR solution; >>NT6) Points T6) and NT5) are too weak to make IP/AC a core >> functionality of ROHC-TCP/CR with respect to violating NT4). >> > > > Please reconsider NT5 and NT6 based on my above comments. > > >>Best regards, >> >>/Ghyslain >> > > > _______________________________________________ > 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 Dec 17 04:33:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00879 for ; Wed, 17 Dec 2003 04:33:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWY3F-0002ub-Hh for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 04:33:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBH9X5ts011193 for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 04:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWY3F-0002uS-2Q for rohc-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 04:33: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 EAA00867 for ; Wed, 17 Dec 2003 04:33:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWY3C-0004f2-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 04:33:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWY39-0004et-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 04:33:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWY39-0004en-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 04:32:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWY3B-0002uA-Ob; Wed, 17 Dec 2003 04:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWY2c-0002t3-BB for rohc@optimus.ietf.org; Wed, 17 Dec 2003 04:32: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 EAA00853 for ; Wed, 17 Dec 2003 04:32:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWY2Z-0004dO-00 for rohc@ietf.org; Wed, 17 Dec 2003 04:32:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWY2X-0004dG-00 for rohc@ietf.org; Wed, 17 Dec 2003 04:32:23 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AWY2W-0004dD-00 for rohc@ietf.org; Wed, 17 Dec 2003 04:32:21 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBH9WK8K019748; Wed, 17 Dec 2003 10:32:20 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Dec 2003 10:32:19 +0100 Message-ID: From: =?iso-8859-1?Q?Fredrik_Lindstr=F6m_=28LU/EAB=29?= To: "'Kristofer Sandlund'" , rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Wed, 17 Dec 2003 10:31:50 +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 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Ghyslain and Kristofer. I don't think IP/AC is important = enough to include in=20 Context Replication. And as Kristofer said it is just "conditionally = non-assertive". /Fredrik Lindstr=F6m -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of Kristofer Sandlund Sent: den 17 december 2003 09:00 To: rohc@ietf.org Subject: Re: [rohc] IP Address Compression for Context Replication Hi all, I'm not going into discussing every point due to lack of time, so I'm = just going to provide my own conclusions of the discussion. I have to agree with Ghyslains summary of the discussion. I don't think = the arguments for IP/AC have managed to convince people that this will save = "enough" or that it will be "applicable enough". Apart from the authors IP/AC, I = haven't really seen support for it. And, as Ghyslain points out, even if the IPR is non-assertive, there = are specific conditions placed on it being non-assertive. Quote from the patent statement: >>> ...provided that the party relying on this commitment does not = assert its >>> patents against Nokia. If it is "conditionally non-assertive", then it is not "non-assertive". Therefore I believe it is still "in violation of" the requirements set = by the WG. I think this is reason enough for not adapting IP/AC. Just my 2 cents. Best regards, Kristofer Sandlund, Effnet AB Yousuf.Saifullah@nokia.com wrote: > Hi Ghyslain, > I am afraid I have to repeat myself a lot in this email. I don't = think the summarization are done correctly in your email. Only partial = views are presented without considering what Zhigang and I have = answered for those views. Even my last email was ignored, which pointed = to those earlier discussion. Please tell me why those statements are = without substance. Please don't just ignore them, give some argument. = Please don't just apply your filter without telling the WG the contents = of your filter :) >=20 > This is the main point, which you are missing. IP/AC can be added = without costing a single bit in replicate_format_0. This can be done by = defining replicate_format_1. The "discriminator" field is defined for = this purpose and will be used to indicate different formats. The IPR = status is "non-assertive", and the IP/AC doesn't need to be optional = and it can be implemented as part of CR by any body. If you have a = single host (last-link), only replicate_format_0 will be used and there = is no overhead. Please see my specific responses below to correctly = reflect the agreement/summary.=20 >=20 > Best Regards, > Yousuf >=20 >=20 >>-----Original Message----- >>From: ext Ghyslain Pelletier [mailto:Ghyslain.Pelletier@ericsson.com] >>Sent: Tuesday, December 16, 2003 9:30 AM >>To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org >>Subject: Re: [rohc] IP Address Compression for Context Replication >> >> >>Hi all, >> >>Actually, as the editor for both impacted documents I have been >>following this thread rather closely and I do not feel that I have >>missed any of the discussions or arguments when writing my=20 >>previous mail >>(http://www1.ietf.org/mail-archive/working-groups/rohc/current >>/msg01899.html). >>I am simply trying to filter out statements without substance to = bring >>up the agreements from my understooding of the list discussion. >> >>I guess I should furhter clarify my previous email regarding=20 >>IP Address >>Compression (IP/AC). I'd invite anyone who's participated to that >>discussion so far to validate or invalidate the following summary, in >>order to help us move on with some form of consensus. >> >>My feeling is that the following agreements have been roughly=20 >>reached on >>this mailing list regarding IP/AC: >> >>Technical aspects >>----------------- >>T1) SUFFIX-Match is unrealistic (out); >>T2) PREFIX-Match is not possible for last-link context >>replication. This >> is because the last link means that the=20 >>compressor/decompressor is=20 >> co-located with the IP endpoint and will not be routing packets=20 >> to/from any subnet >=20 >=20 > Prefix match is quite possible in other viable scenarios. I have = mentioned them before. Why we have to limit our solution to the = last-link CR, with one host at the end. We should not limit our = solutions based on something we thought two years ago, otherwise the = solution would be deficient. We may end up revising the draft soon. = Please add this point. >=20 >=20 >>T3) ROHC-CR has been originally motivated for cases when at least one >> IP address was the same - this being the trigger for replication. >> Given this, it makes less sense to attempt to compress = differently >> IP address; >=20 >=20 > We should try to develop a good solution, considering our latest = knowledge and foresight. Why we have to limit ourselves to what we = thought originally. Isn't ROHC-CR under development? Make ROHC-CR = applicable for multiple hosts also.=20 >=20 >=20 >>T4) Defining a separate packet format for a "feature" does=20 >>not make the >> "feature" optional - decompressor is still forced to implement it = >> unless some form of negotiation is used or separate profiles; >=20 >=20 > This tells me that you have missed some emails on this thread. Please = read my emails on this topic. I am not asking you to make the feature = optional at all. Implement IP Address Compression on both ends as = mandatory feature. The IPR status is changed to "non-assertive", = everyone in the world can implement this IPR. We will use separate = packet formats to save the cost in terms of bit. >=20 >=20 >=20 >>T5) Any potentially noticeable gain would only occur with=20 >>IPv6/HTTP1.1=20 >> (persistent TCP connection), not with IPv4 or HTTP1.0. Persistent >> connections are probably longer-lived and, therefore, the=20 >>impact of >> any kind of replication is lower, making IP/AC even less=20 >> significant with respect to IPv6/HTTP1.1; >=20 >=20 > This is incorrect I have challenged it in my last email, but you = didn't replied. Please do not repeat the above without commenting on = the text below.=20 >=20 > If I use replicate_format_0 in the cases of 1 host and 1 server, and = I use replicate_format_1 with additional 2 bits needed for the = ip_src/dst_addr.discriminator. The gain is with IPv4 and HTTP 1.0 also. = Let me explain it again. You are only considering analysis sent by = Kristofer, without including the follow-up analysis and development. = Kristofer's analysis considers saving in multiple connections between 1 = host and 1 server, considering the cost of the above 2 additional bits. = He assumed that we have only one structure, replicate_format_0 and we = have to fit this IP addresss compression in the same structure. Later, = we realized that we can use two separate structures using = "discriminator" bits. If we use separate structures, we don't have = additional cost of 2 bits for IP/AC. When we don't have IP/AC, e.g. = multiple connections between 1 host and 1 server, we will use = replicate_format_0. When we have IP/AC, e.g. multiple hosts, we will = use replicate_format_1. Thus, Kristof er's analysis for cost becomes invalid. >=20 > I think the above is an important point which is being missed. >=20 > The following are the possible cases now: >=20 > Case-1: Single Host ; no impact, replicate_format_0 will be used in = this case. The discriminator will indicate a structure without IP = address compression. There will be *no additional cost* for single host = due to ip_src/dest_addr.discriminator bits. No change for = IPv4/v6/HTTP1.0/1.1, everything stays as it is now in the current = ROHC-CR and ROHC-TCP draft. >=20 > Case-2: Multiple Hosts; the discriminator will indicate a structure = with IP address compression, e.g. replicate_format_1 as I proposed in = this email = (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01897.= html). There will always be saving if a prefix match is found. A host = uses another hosts base context for IP address replication. For "m" new = connection, the saving will be m*(x-matched_len). With half as prefix = match. For IPv6, saving is m*60 bits; and for IPv4 saving is m*14 bits. = Pick a value of m, if what I have mentiond sounds (...) :). Also, I = have chosen byte-wise matched-len as mentioned in this email = (http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01884.= html) >=20 >=20 >=20 >>T6) Any potential gain with IP/AC is not of major significance, also=20 >> considering that IR-CR is already an optimization of the=20 >> initialization procedure only (see also NT3). >=20 >=20 > My above comments nullifies this conclusion. If you don't agree, = please tell me why not. >=20 >=20 >>Non-technical aspects >>--------------------- >>NT1) Motivations for the "field behavior" addressed by ROHC-TCP/CR HC = >> has been extensively discussed and agreed. Addressing a=20 >>different=20 >> type of behavior must be properly motivated - just like=20 >>behaviors=20 >> currently addressed. >=20 >=20 > Please see my comment under NT3. >=20 >=20 >>NT2) The fact that some bits are currently used for byte-alignment in = >> the TCP IR-CR packet formats is not a motivation for including=20 >> IP/AC; >=20 >=20 > IP/AC is not asking to use any byte-alignment bits. Again, you are = missing the point and earlier emails from me. I have repeated this = above. Please let me know what is not clear in my statements.=20 >=20 >=20 >>NT3) Applicability of IP/AC (mobile router and satellite links - i.e. = >> not last-link) is limited and not the most expected case; >=20 >=20 >=20 > We should not limit our solution for only "one" case, which we = thought two years ago during the "field behavior" discussion. We have = missed some case at that time, and now we have chance to include them. = Why not broaden the solution to these likely cases? Especially, when = doing so is not costing a bit for the previously thought case. In fact, = it is saving more bits and will make CR more efficient.=20 >=20 > I am not suggesting IP/AC, when the ROHC-CR or ROHC-TCP are frozen = for further changes. I am suggesting them while we are discussing and = inviting comments on these drafts. I think any hesitation based on our = previously set mind should be questionable. >=20 >=20 >>NT4) A requirement regarding IPRs was agreed by the wg for the TCP=20 >> solution. I understand the meaning of "non-assertive" >> (as read from=20 >>http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft >> -saifullah-rohc-ip-addr-comp-context-replicat.txt), >> but the IPR statement still mentions some limitations as to the=20 >> non-assertivness of the IPR being only valid if other=20 >>companies do=20 >> not assert ANY patents against Nokia (even patents not related = to >> ROHC); >=20 >=20 > The text "(even patents not related to ROHC)" is not on the IPR = web-site. It was added by you. I am copying the whole text below for = the benefit of others:=20 >=20 > "This is an update to the earlier Nokia IPR disclosure to=20 > the subject draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt = > (submitted on 2.12.2003). >=20 > This is to advise the IETF that Nokia has pending unpublished=20 > patent application > "Compressing header data" that may relate to the Internet Draft=20 > submission: IP Address Compression in Context Replication=20 > (draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt). >=20 > Regarding this Internet Draft submission=20 > draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt,=20 > to the extent this submission is included into final IETF=20 > standard spesification, Nokia agrees > not to assert those claims in Nokia patents that apply to this=20 > submission and are technically necessary to implement the IETF=20 > standard spesification against any other party in respect of its=20 > implementation of the specification, provided that the party relying=20 > on this commitment does not assert its patents against Nokia." >=20 > I am not a legal expert, but the above statement read perfectly = neutral to me. I would encourage other mailing list participants also = to explain to me why the above statement is not neutral. =20 >=20 >=20 >=20 >>NT5) The scenarios for motivating the occurence of=20 >>PREFIX-Match are too=20 >> weak for including IP/AC in the ROHC-TCP/CR solution; >>NT6) Points T6) and NT5) are too weak to make IP/AC a core >> functionality of ROHC-TCP/CR with respect to violating NT4). >> >=20 >=20 > Please reconsider NT5 and NT6 based on my above comments. >=20 >=20 >>Best regards, >> >>/Ghyslain >> >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Dec 17 05:10:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01953 for ; Wed, 17 Dec 2003 05:10:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYd5-0004I1-O1 for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 05:10:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHAA6rq016427 for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 05:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYd4-0004Gq-FD for rohc-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 05:10: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 FAA01933 for ; Wed, 17 Dec 2003 05:10:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWYd1-0005Pp-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 05:10:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWYcz-0005Pi-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 05:10:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWYcz-0005Pf-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 05:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYd0-0004GU-JZ; Wed, 17 Dec 2003 05:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYcw-0004G8-Rt for rohc@optimus.ietf.org; Wed, 17 Dec 2003 05:09:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01929 for ; Wed, 17 Dec 2003 05:09:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWYct-0005Pb-00 for rohc@ietf.org; Wed, 17 Dec 2003 05:09:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWYcr-0005PU-00 for rohc@ietf.org; Wed, 17 Dec 2003 05:09:55 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AWYcq-0005PP-00 for rohc@ietf.org; Wed, 17 Dec 2003 05:09:52 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Dec 2003 10:09:17 -0000 Message-ID: From: "West, Mark" To: "'Yousuf.Saifullah@nokia.com'" , Ghyslain.Pelletier@ericsson.com, rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Wed, 17 Dec 2003 10:09:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Yousuf, I think that the 'cost' of adding an additional replicate format is non-negligible... The reason why there is a single replicate packet is because you want to allow pretty much all combinations of changes. Having multiple replicate packets means that you have to (ahem) replicate much of the base packet format. This makes more text in the draft (ok, maybe not a big deal) and has to be accommodated in implementations. Kristofer may like to comment on that..! But it's more complexity and more to document / implement and more to go wrong! My view is that the IR-Replicate format for TCP is already complicated enough (in fact, I'd much rather make it simpler than add more to it...) IR-Replicate is an optimisation to improve the compression of short-lived flows. If we accept this, then keeping the complexity of replication low is a desirable goal since there are many scenarios where it won't actually achieve anything. Insofar as the conditional non-assertion applies to this standard (i.e. the patent is only asserted against those who claim IPR on *this* standard), I don't have a problem with that. However, IANAL... At the moment, we've got enough work on our plates trying to knock *all* the packet formats into shape, without getting mired in an argument about replication. Constructive help on straightening everything else out would be much more useful, to me at least... Thanks, Mark. > -----Original Message----- > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > Sent: 17 December 2003 00:35 > To: Ghyslain.Pelletier@ericsson.com; rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication > > > Hi Ghyslain, > I am afraid I have to repeat myself a lot in this email. I > don't think the summarization are done correctly in your > email. Only partial views are presented without considering > what Zhigang and I have answered for those views. Even my > last email was ignored, which pointed to those earlier > discussion. Please tell me why those statements are without > substance. Please don't just ignore them, give some argument. > Please don't just apply your filter without telling the WG > the contents of your filter :) > > This is the main point, which you are missing. IP/AC can be > added without costing a single bit in replicate_format_0. > This can be done by defining replicate_format_1. The > "discriminator" field is defined for this purpose and will be > used to indicate different formats. The IPR status is > "non-assertive", and the IP/AC doesn't need to be optional > and it can be implemented as part of CR by any body. If you > have a single host (last-link), only replicate_format_0 will > be used and there is no overhead. Please see my specific > responses below to correctly reflect the agreement/summary. > > Best Regards, > Yousuf > > > -----Original Message----- > > From: ext Ghyslain Pelletier > [mailto:Ghyslain.Pelletier@ericsson.com] > > Sent: Tuesday, December 16, 2003 9:30 AM > > To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org > > Subject: Re: [rohc] IP Address Compression for Context Replication > > > > > > Hi all, > > > > Actually, as the editor for both impacted documents I have been > > following this thread rather closely and I do not feel that I have > > missed any of the discussions or arguments when writing my > > previous mail > > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > > /msg01899.html). > > I am simply trying to filter out statements without > substance to bring > > up the agreements from my understooding of the list discussion. > > > > I guess I should furhter clarify my previous email regarding > > IP Address > > Compression (IP/AC). I'd invite anyone who's participated to that > > discussion so far to validate or invalidate the following > summary, in > > order to help us move on with some form of consensus. > > > > My feeling is that the following agreements have been roughly > > reached on > > this mailing list regarding IP/AC: > > > > Technical aspects > > ----------------- > > T1) SUFFIX-Match is unrealistic (out); > > T2) PREFIX-Match is not possible for last-link context > > replication. This > > is because the last link means that the > > compressor/decompressor is > > co-located with the IP endpoint and will not be routing packets > > to/from any subnet > > Prefix match is quite possible in other viable scenarios. I > have mentioned them before. Why we have to limit our solution > to the last-link CR, with one host at the end. We should not > limit our solutions based on something we thought two years > ago, otherwise the solution would be deficient. We may end up > revising the draft soon. Please add this point. > > > T3) ROHC-CR has been originally motivated for cases when at > least one > > IP address was the same - this being the trigger for > replication. > > Given this, it makes less sense to attempt to compress > differently > > IP address; > > We should try to develop a good solution, considering our > latest knowledge and foresight. Why we have to limit > ourselves to what we thought originally. Isn't ROHC-CR under > development? Make ROHC-CR applicable for multiple hosts also. > > > T4) Defining a separate packet format for a "feature" does > > not make the > > "feature" optional - decompressor is still forced to > implement it > > unless some form of negotiation is used or separate profiles; > > This tells me that you have missed some emails on this > thread. Please read my emails on this topic. I am not asking > you to make the feature optional at all. Implement IP Address > Compression on both ends as mandatory feature. The IPR status > is changed to "non-assertive", everyone in the world can > implement this IPR. We will use separate packet formats to > save the cost in terms of bit. > > > > T5) Any potentially noticeable gain would only occur with > > IPv6/HTTP1.1 > > (persistent TCP connection), not with IPv4 or HTTP1.0. > Persistent > > connections are probably longer-lived and, therefore, the > > impact of > > any kind of replication is lower, making IP/AC even less > > significant with respect to IPv6/HTTP1.1; > > This is incorrect I have challenged it in my last email, but > you didn't replied. Please do not repeat the above without > commenting on the text below. > > If I use replicate_format_0 in the cases of 1 host and 1 > server, and I use replicate_format_1 with additional 2 bits > needed for the ip_src/dst_addr.discriminator. The gain is > with IPv4 and HTTP 1.0 also. Let me explain it again. You are > only considering analysis sent by Kristofer, without > including the follow-up analysis and development. > Kristofer's analysis considers saving in multiple connections > between 1 host and 1 server, considering the cost of the > above 2 additional bits. He assumed that we have only one > structure, replicate_format_0 and we have to fit this IP > addresss compression in the same structure. Later, we > realized that we can use two separate structures using > "discriminator" bits. If we use separate structures, we don't > have additional cost of 2 bits for IP/AC. When we don't have > IP/AC, e.g. multiple connections between 1 host and 1 server, > we will use replicate_format_0. When we have IP/AC, e.g. > multiple hosts, we will use replicate_format_1. Thus, > Kristofer's analysis for cost becomes invalid. > > I think the above is an important point which is being missed. > > The following are the possible cases now: > > Case-1: Single Host ; no impact, replicate_format_0 will be > used in this case. The discriminator will indicate a > structure without IP address compression. There will be *no > additional cost* for single host due to > ip_src/dest_addr.discriminator bits. No change for > IPv4/v6/HTTP1.0/1.1, everything stays as it is now in the > current ROHC-CR and ROHC-TCP draft. > > Case-2: Multiple Hosts; the discriminator will indicate a > structure with IP address compression, e.g. > replicate_format_1 as I proposed in this email > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > /msg01897.html). There will always be saving if a prefix > match is found. A host uses another hosts base context for IP > address replication. For "m" new connection, the saving will > be m*(x-matched_len). With half as prefix match. For IPv6, > saving is m*60 bits; and for IPv4 saving is m*14 bits. Pick a > value of m, if what I have mentiond sounds (...) :). Also, I > have chosen byte-wise matched-len as mentioned in this email > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > /msg01884.html) > > > > T6) Any potential gain with IP/AC is not of major > significance, also > > considering that IR-CR is already an optimization of the > > initialization procedure only (see also NT3). > > My above comments nullifies this conclusion. If you don't > agree, please tell me why not. > > > > > Non-technical aspects > > --------------------- > > NT1) Motivations for the "field behavior" addressed by > ROHC-TCP/CR HC > > has been extensively discussed and agreed. Addressing a > > different > > type of behavior must be properly motivated - just like > > behaviors > > currently addressed. > > Please see my comment under NT3. > > > NT2) The fact that some bits are currently used for > byte-alignment in > > the TCP IR-CR packet formats is not a motivation for including > > IP/AC; > > IP/AC is not asking to use any byte-alignment bits. Again, > you are missing the point and earlier emails from me. I have > repeated this above. Please let me know what is not clear in > my statements. > > > NT3) Applicability of IP/AC (mobile router and satellite > links - i.e. > > not last-link) is limited and not the most expected case; > > > We should not limit our solution for only "one" case, which > we thought two years ago during the "field behavior" > discussion. We have missed some case at that time, and now we > have chance to include them. Why not broaden the solution to > these likely cases? Especially, when doing so is not costing > a bit for the previously thought case. In fact, it is saving > more bits and will make CR more efficient. > > I am not suggesting IP/AC, when the ROHC-CR or ROHC-TCP are > frozen for further changes. I am suggesting them while we are > discussing and inviting comments on these drafts. I think any > hesitation based on our previously set mind should be questionable. > > > NT4) A requirement regarding IPRs was agreed by the wg for the TCP > > solution. I understand the meaning of "non-assertive" > > (as read from > > http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft > > -saifullah-rohc-ip-addr-comp-context-replicat.txt), > > but the IPR statement still mentions some limitations > as to the > > non-assertivness of the IPR being only valid if other > > companies do > > not assert ANY patents against Nokia (even patents not > related to > > ROHC); > > The text "(even patents not related to ROHC)" is not on the > IPR web-site. It was added by you. I am copying the whole > text below for the benefit of others: > > "This is an update to the earlier Nokia IPR disclosure to > the subject draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt > (submitted on 2.12.2003). > > This is to advise the IETF that Nokia has pending unpublished > patent application > "Compressing header data" that may relate to the Internet Draft > submission: IP Address Compression in Context Replication > (draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt). > > Regarding this Internet Draft submission > draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt, > to the extent this submission is included into final IETF > standard spesification, Nokia agrees > not to assert those claims in Nokia patents that apply to this > submission and are technically necessary to implement the IETF > standard spesification against any other party in respect of its > implementation of the specification, provided that the party relying > on this commitment does not assert its patents against Nokia." > > I am not a legal expert, but the above statement read > perfectly neutral to me. I would encourage other mailing list > participants also to explain to me why the above statement is > not neutral. > > > > NT5) The scenarios for motivating the occurence of > > PREFIX-Match are too > > weak for including IP/AC in the ROHC-TCP/CR solution; > > NT6) Points T6) and NT5) are too weak to make IP/AC a core > > functionality of ROHC-TCP/CR with respect to violating NT4). > > > > Please reconsider NT5 and NT6 based on my above comments. > > > Best regards, > > > > /Ghyslain > > > > _______________________________________________ > 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 Dec 17 06:44:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04015 for ; Wed, 17 Dec 2003 06:44:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWa60-0007Ej-Ne for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 06:44:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHBi48N027811 for rohc-archive@odin.ietf.org; Wed, 17 Dec 2003 06: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 1AWa60-0007EU-Hu for rohc-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 06: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 GAA03980 for ; Wed, 17 Dec 2003 06:44:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWa5w-0007Ml-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 06:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWa5u-0007Me-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 06:43:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWa5u-0007Mb-00 for rohc-web-archive@ietf.org; Wed, 17 Dec 2003 06:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWa5x-0007EF-Iy; Wed, 17 Dec 2003 06:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWa5m-0007E4-Rq for rohc@optimus.ietf.org; Wed, 17 Dec 2003 06:43:51 -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 GAA03977 for ; Wed, 17 Dec 2003 06:43:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWa5i-0007MX-00 for rohc@ietf.org; Wed, 17 Dec 2003 06:43:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWa5h-0007MQ-00 for rohc@ietf.org; Wed, 17 Dec 2003 06:43:46 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AWa5g-0007La-00 for rohc@ietf.org; Wed, 17 Dec 2003 06:43:44 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Dec 2003 11:43:11 -0000 Message-ID: From: "West, Mark" To: "'Kristofer Sandlund'" , rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Wed, 17 Dec 2003 11:43:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Kristofer, all, I specifically addressed the complexity issue in another mail... ... however, let me take this opportunity to say that I agree with Ghyslain's summary of the discussion and with Kristofer's response (and that I share his concerns). Cheers, Mark. > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: 17 December 2003 08:00 > To: rohc@ietf.org > Subject: Re: [rohc] IP Address Compression for Context Replication > > > Hi all, > > I'm not going into discussing every point due to lack of > time, so I'm just going > to provide my own conclusions of the discussion. > > I have to agree with Ghyslains summary of the discussion. I > don't think the > arguments for IP/AC have managed to convince people that this > will save "enough" > or that it will be "applicable enough". Apart from the > authors IP/AC, I haven't > really seen support for it. > And, as Ghyslain points out, even if the IPR is > non-assertive, there are > specific conditions placed on it being non-assertive. > Quote from the patent statement: > >>> ...provided that the party relying on this commitment > does not assert its > >>> patents against Nokia. > If it is "conditionally non-assertive", then it is not > "non-assertive". > Therefore I believe it is still "in violation of" the > requirements set by the > WG. I think this is reason enough for not adapting IP/AC. > > Just my 2 cents. > > Best regards, > Kristofer Sandlund, Effnet AB > > Yousuf.Saifullah@nokia.com wrote: > > Hi Ghyslain, > > I am afraid I have to repeat myself a lot in this email. I > don't think the summarization are done correctly in your > email. Only partial views are presented without considering > what Zhigang and I have answered for those views. Even my > last email was ignored, which pointed to those earlier > discussion. Please tell me why those statements are without > substance. Please don't just ignore them, give some argument. > Please don't just apply your filter without telling the WG > the contents of your filter :) > > > > This is the main point, which you are missing. IP/AC can be > added without costing a single bit in replicate_format_0. > This can be done by defining replicate_format_1. The > "discriminator" field is defined for this purpose and will be > used to indicate different formats. The IPR status is > "non-assertive", and the IP/AC doesn't need to be optional > and it can be implemented as part of CR by any body. If you > have a single host (last-link), only replicate_format_0 will > be used and there is no overhead. Please see my specific > responses below to correctly reflect the agreement/summary. > > > > Best Regards, > > Yousuf > > > > > >>-----Original Message----- > >>From: ext Ghyslain Pelletier > [mailto:Ghyslain.Pelletier@ericsson.com] > >>Sent: Tuesday, December 16, 2003 9:30 AM > >>To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org > >>Subject: Re: [rohc] IP Address Compression for Context Replication > >> > >> > >>Hi all, > >> > >>Actually, as the editor for both impacted documents I have been > >>following this thread rather closely and I do not feel that I have > >>missed any of the discussions or arguments when writing my > >>previous mail > >>(http://www1.ietf.org/mail-archive/working-groups/rohc/current > >>/msg01899.html). > >>I am simply trying to filter out statements without > substance to bring > >>up the agreements from my understooding of the list discussion. > >> > >>I guess I should furhter clarify my previous email regarding > >>IP Address > >>Compression (IP/AC). I'd invite anyone who's participated to that > >>discussion so far to validate or invalidate the following > summary, in > >>order to help us move on with some form of consensus. > >> > >>My feeling is that the following agreements have been roughly > >>reached on > >>this mailing list regarding IP/AC: > >> > >>Technical aspects > >>----------------- > >>T1) SUFFIX-Match is unrealistic (out); > >>T2) PREFIX-Match is not possible for last-link context > >>replication. This > >> is because the last link means that the > >>compressor/decompressor is > >> co-located with the IP endpoint and will not be routing packets > >> to/from any subnet > > > > > > Prefix match is quite possible in other viable scenarios. I > have mentioned them before. Why we have to limit our solution > to the last-link CR, with one host at the end. We should not > limit our solutions based on something we thought two years > ago, otherwise the solution would be deficient. We may end up > revising the draft soon. Please add this point. > > > > > >>T3) ROHC-CR has been originally motivated for cases when at > least one > >> IP address was the same - this being the trigger for > replication. > >> Given this, it makes less sense to attempt to compress > differently > >> IP address; > > > > > > We should try to develop a good solution, considering our > latest knowledge and foresight. Why we have to limit > ourselves to what we thought originally. Isn't ROHC-CR under > development? Make ROHC-CR applicable for multiple hosts also. > > > > > >>T4) Defining a separate packet format for a "feature" does > >>not make the > >> "feature" optional - decompressor is still forced to > implement it > >> unless some form of negotiation is used or separate profiles; > > > > > > This tells me that you have missed some emails on this > thread. Please read my emails on this topic. I am not asking > you to make the feature optional at all. Implement IP Address > Compression on both ends as mandatory feature. The IPR status > is changed to "non-assertive", everyone in the world can > implement this IPR. We will use separate packet formats to > save the cost in terms of bit. > > > > > > > >>T5) Any potentially noticeable gain would only occur with > >>IPv6/HTTP1.1 > >> (persistent TCP connection), not with IPv4 or HTTP1.0. > Persistent > >> connections are probably longer-lived and, therefore, the > >>impact of > >> any kind of replication is lower, making IP/AC even less > >> significant with respect to IPv6/HTTP1.1; > > > > > > This is incorrect I have challenged it in my last email, > but you didn't replied. Please do not repeat the above > without commenting on the text below. > > > > If I use replicate_format_0 in the cases of 1 host and 1 > server, and I use replicate_format_1 with additional 2 bits > needed for the ip_src/dst_addr.discriminator. The gain is > with IPv4 and HTTP 1.0 also. Let me explain it again. You are > only considering analysis sent by Kristofer, without > including the follow-up analysis and development. > Kristofer's analysis considers saving in multiple connections > between 1 host and 1 server, considering the cost of the > above 2 additional bits. He assumed that we have only one > structure, replicate_format_0 and we have to fit this IP > addresss compression in the same structure. Later, we > realized that we can use two separate structures using > "discriminator" bits. If we use separate structures, we don't > have additional cost of 2 bits for IP/AC. When we don't have > IP/AC, e.g. multiple connections between 1 host and 1 server, > we will use replicate_format_0. When we have IP/AC, e.g. > multiple hosts, we will use replicate_format_1. Thus, Kristof > > er's analysis for cost becomes invalid. > > > > I think the above is an important point which is being missed. > > > > The following are the possible cases now: > > > > Case-1: Single Host ; no impact, replicate_format_0 will be > used in this case. The discriminator will indicate a > structure without IP address compression. There will be *no > additional cost* for single host due to > ip_src/dest_addr.discriminator bits. No change for > IPv4/v6/HTTP1.0/1.1, everything stays as it is now in the > current ROHC-CR and ROHC-TCP draft. > > > > Case-2: Multiple Hosts; the discriminator will indicate a > structure with IP address compression, e.g. > replicate_format_1 as I proposed in this email > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > /msg01897.html). There will always be saving if a prefix > match is found. A host uses another hosts base context for IP > address replication. For "m" new connection, the saving will > be m*(x-matched_len). With half as prefix match. For IPv6, > saving is m*60 bits; and for IPv4 saving is m*14 bits. Pick a > value of m, if what I have mentiond sounds (...) :). Also, I > have chosen byte-wise matched-len as mentioned in this email > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > /msg01884.html) > > > > > > > >>T6) Any potential gain with IP/AC is not of major > significance, also > >> considering that IR-CR is already an optimization of the > >> initialization procedure only (see also NT3). > > > > > > My above comments nullifies this conclusion. If you don't > agree, please tell me why not. > > > > > >>Non-technical aspects > >>--------------------- > >>NT1) Motivations for the "field behavior" addressed by > ROHC-TCP/CR HC > >> has been extensively discussed and agreed. Addressing a > >>different > >> type of behavior must be properly motivated - just like > >>behaviors > >> currently addressed. > > > > > > Please see my comment under NT3. > > > > > >>NT2) The fact that some bits are currently used for > byte-alignment in > >> the TCP IR-CR packet formats is not a motivation for including > >> IP/AC; > > > > > > IP/AC is not asking to use any byte-alignment bits. Again, > you are missing the point and earlier emails from me. I have > repeated this above. Please let me know what is not clear in > my statements. > > > > > >>NT3) Applicability of IP/AC (mobile router and satellite > links - i.e. > >> not last-link) is limited and not the most expected case; > > > > > > > > We should not limit our solution for only "one" case, which > we thought two years ago during the "field behavior" > discussion. We have missed some case at that time, and now we > have chance to include them. Why not broaden the solution to > these likely cases? Especially, when doing so is not costing > a bit for the previously thought case. In fact, it is saving > more bits and will make CR more efficient. > > > > I am not suggesting IP/AC, when the ROHC-CR or ROHC-TCP are > frozen for further changes. I am suggesting them while we are > discussing and inviting comments on these drafts. I think any > hesitation based on our previously set mind should be questionable. > > > > > >>NT4) A requirement regarding IPRs was agreed by the wg for the TCP > >> solution. I understand the meaning of "non-assertive" > >> (as read from > >>http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft > >> -saifullah-rohc-ip-addr-comp-context-replicat.txt), > >> but the IPR statement still mentions some limitations > as to the > >> non-assertivness of the IPR being only valid if other > >>companies do > >> not assert ANY patents against Nokia (even patents not > related to > >> ROHC); > > > > > > The text "(even patents not related to ROHC)" is not on the > IPR web-site. It was added by you. I am copying the whole > text below for the benefit of others: > > > > "This is an update to the earlier Nokia IPR disclosure to > > the subject > draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt > > (submitted on 2.12.2003). > > > > This is to advise the IETF that Nokia has pending unpublished > > patent application > > "Compressing header data" that may relate to the Internet Draft > > submission: IP Address Compression in Context Replication > > (draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt). > > > > Regarding this Internet Draft submission > > draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt, > > to the extent this submission is included into final IETF > > standard spesification, Nokia agrees > > not to assert those claims in Nokia patents that apply to this > > submission and are technically necessary to implement the IETF > > standard spesification against any other party in respect of its > > implementation of the specification, provided that the > party relying > > on this commitment does not assert its patents against Nokia." > > > > I am not a legal expert, but the above statement read > perfectly neutral to me. I would encourage other mailing list > participants also to explain to me why the above statement is > not neutral. > > > > > > > >>NT5) The scenarios for motivating the occurence of > >>PREFIX-Match are too > >> weak for including IP/AC in the ROHC-TCP/CR solution; > >>NT6) Points T6) and NT5) are too weak to make IP/AC a core > >> functionality of ROHC-TCP/CR with respect to violating NT4). > >> > > > > > > Please reconsider NT5 and NT6 based on my above comments. > > > > > >>Best regards, > >> > >>/Ghyslain > >> > > > > > > _______________________________________________ > > 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 Dec 18 06:37:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15903 for ; Thu, 18 Dec 2003 06:37:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwSo-0004Fl-2l for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 06:37:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIBb5nB016335 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 06:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwSn-0004FG-Ks for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 06:37: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 GAA15892 for ; Thu, 18 Dec 2003 06:37:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwSj-0002Q7-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:37:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwSh-0002Q0-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:37:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwSh-0002Px-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06: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 1AWwSi-0004Dt-Rw; Thu, 18 Dec 2003 06: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 1AWwSb-0004DR-Pp for rohc@optimus.ietf.org; Thu, 18 Dec 2003 06:36:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15877 for ; Thu, 18 Dec 2003 06:36:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwSX-0002PU-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:36:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwSW-0002PN-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:36:49 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AWwSV-0002PK-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:36:47 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBIBalSs028464; Thu, 18 Dec 2003 12:36:47 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Dec 2003 12:36:47 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "West, Mark" , "'Yousuf.Saifullah@nokia.com'" , "Ghyslain.Pelletier@ericsson.com" , rohc@ietf.org Subject: RE: [rohc] IP Address Compression for Context Replication Date: Thu, 18 Dec 2003 12:36:15 +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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, I come to the same conclusion as others on this issue, and I also agree with Marks opinion that we should rather simplify CR than making it more complex. CR is itself an optimization, and we should learn from previous mistakes when it comes to complexity. /L-E > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On > Behalf Of West, > Mark > Sent: den 17 december 2003 11:09 > To: 'Yousuf.Saifullah@nokia.com'; Ghyslain Pelletier (LU/EAB); > rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication > > > > Hi Yousuf, > > I think that the 'cost' of adding an additional replicate format is > non-negligible... > > The reason why there is a single replicate packet is because > you want to > allow pretty much all combinations of changes. Having > multiple replicate > packets means that you have to (ahem) replicate much of the > base packet > format. This makes more text in the draft (ok, maybe not a > big deal) and > has to be accommodated in implementations. Kristofer may > like to comment on > that..! But it's more complexity and more to document / > implement and more > to go wrong! > > My view is that the IR-Replicate format for TCP is already complicated > enough (in fact, I'd much rather make it simpler than add > more to it...) > > IR-Replicate is an optimisation to improve the compression of > short-lived > flows. If we accept this, then keeping the complexity of > replication low is > a desirable goal since there are many scenarios where it > won't actually > achieve anything. > > Insofar as the conditional non-assertion applies to this > standard (i.e. the > patent is only asserted against those who claim IPR on *this* > standard), I > don't have a problem with that. However, IANAL... > > At the moment, we've got enough work on our plates trying to > knock *all* the > packet formats into shape, without getting mired in an argument about > replication. Constructive help on straightening everything > else out would > be much more useful, to me at least... > > Thanks, > > Mark. > > > > > -----Original Message----- > > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > > Sent: 17 December 2003 00:35 > > To: Ghyslain.Pelletier@ericsson.com; rohc@ietf.org > > Subject: RE: [rohc] IP Address Compression for Context Replication > > > > > > Hi Ghyslain, > > I am afraid I have to repeat myself a lot in this email. I > > don't think the summarization are done correctly in your > > email. Only partial views are presented without considering > > what Zhigang and I have answered for those views. Even my > > last email was ignored, which pointed to those earlier > > discussion. Please tell me why those statements are without > > substance. Please don't just ignore them, give some argument. > > Please don't just apply your filter without telling the WG > > the contents of your filter :) > > > > This is the main point, which you are missing. IP/AC can be > > added without costing a single bit in replicate_format_0. > > This can be done by defining replicate_format_1. The > > "discriminator" field is defined for this purpose and will be > > used to indicate different formats. The IPR status is > > "non-assertive", and the IP/AC doesn't need to be optional > > and it can be implemented as part of CR by any body. If you > > have a single host (last-link), only replicate_format_0 will > > be used and there is no overhead. Please see my specific > > responses below to correctly reflect the agreement/summary. > > > > Best Regards, > > Yousuf > > > > > -----Original Message----- > > > From: ext Ghyslain Pelletier > > [mailto:Ghyslain.Pelletier@ericsson.com] > > > Sent: Tuesday, December 16, 2003 9:30 AM > > > To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org > > > Subject: Re: [rohc] IP Address Compression for Context Replication > > > > > > > > > Hi all, > > > > > > Actually, as the editor for both impacted documents I have been > > > following this thread rather closely and I do not feel that I have > > > missed any of the discussions or arguments when writing my > > > previous mail > > > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > > > /msg01899.html). > > > I am simply trying to filter out statements without > > substance to bring > > > up the agreements from my understooding of the list discussion. > > > > > > I guess I should furhter clarify my previous email regarding > > > IP Address > > > Compression (IP/AC). I'd invite anyone who's participated to that > > > discussion so far to validate or invalidate the following > > summary, in > > > order to help us move on with some form of consensus. > > > > > > My feeling is that the following agreements have been roughly > > > reached on > > > this mailing list regarding IP/AC: > > > > > > Technical aspects > > > ----------------- > > > T1) SUFFIX-Match is unrealistic (out); > > > T2) PREFIX-Match is not possible for last-link context > > > replication. This > > > is because the last link means that the > > > compressor/decompressor is > > > co-located with the IP endpoint and will not be > routing packets > > > to/from any subnet > > > > Prefix match is quite possible in other viable scenarios. I > > have mentioned them before. Why we have to limit our solution > > to the last-link CR, with one host at the end. We should not > > limit our solutions based on something we thought two years > > ago, otherwise the solution would be deficient. We may end up > > revising the draft soon. Please add this point. > > > > > T3) ROHC-CR has been originally motivated for cases when at > > least one > > > IP address was the same - this being the trigger for > > replication. > > > Given this, it makes less sense to attempt to compress > > differently > > > IP address; > > > > We should try to develop a good solution, considering our > > latest knowledge and foresight. Why we have to limit > > ourselves to what we thought originally. Isn't ROHC-CR under > > development? Make ROHC-CR applicable for multiple hosts also. > > > > > T4) Defining a separate packet format for a "feature" does > > > not make the > > > "feature" optional - decompressor is still forced to > > implement it > > > unless some form of negotiation is used or separate profiles; > > > > This tells me that you have missed some emails on this > > thread. Please read my emails on this topic. I am not asking > > you to make the feature optional at all. Implement IP Address > > Compression on both ends as mandatory feature. The IPR status > > is changed to "non-assertive", everyone in the world can > > implement this IPR. We will use separate packet formats to > > save the cost in terms of bit. > > > > > > > T5) Any potentially noticeable gain would only occur with > > > IPv6/HTTP1.1 > > > (persistent TCP connection), not with IPv4 or HTTP1.0. > > Persistent > > > connections are probably longer-lived and, therefore, the > > > impact of > > > any kind of replication is lower, making IP/AC even less > > > significant with respect to IPv6/HTTP1.1; > > > > This is incorrect I have challenged it in my last email, but > > you didn't replied. Please do not repeat the above without > > commenting on the text below. > > > > If I use replicate_format_0 in the cases of 1 host and 1 > > server, and I use replicate_format_1 with additional 2 bits > > needed for the ip_src/dst_addr.discriminator. The gain is > > with IPv4 and HTTP 1.0 also. Let me explain it again. You are > > only considering analysis sent by Kristofer, without > > including the follow-up analysis and development. > > Kristofer's analysis considers saving in multiple connections > > between 1 host and 1 server, considering the cost of the > > above 2 additional bits. He assumed that we have only one > > structure, replicate_format_0 and we have to fit this IP > > addresss compression in the same structure. Later, we > > realized that we can use two separate structures using > > "discriminator" bits. If we use separate structures, we don't > > have additional cost of 2 bits for IP/AC. When we don't have > > IP/AC, e.g. multiple connections between 1 host and 1 server, > > we will use replicate_format_0. When we have IP/AC, e.g. > > multiple hosts, we will use replicate_format_1. Thus, > > Kristofer's analysis for cost becomes invalid. > > > > I think the above is an important point which is being missed. > > > > The following are the possible cases now: > > > > Case-1: Single Host ; no impact, replicate_format_0 will be > > used in this case. The discriminator will indicate a > > structure without IP address compression. There will be *no > > additional cost* for single host due to > > ip_src/dest_addr.discriminator bits. No change for > > IPv4/v6/HTTP1.0/1.1, everything stays as it is now in the > > current ROHC-CR and ROHC-TCP draft. > > > > Case-2: Multiple Hosts; the discriminator will indicate a > > structure with IP address compression, e.g. > > replicate_format_1 as I proposed in this email > > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > > /msg01897.html). There will always be saving if a prefix > > match is found. A host uses another hosts base context for IP > > address replication. For "m" new connection, the saving will > > be m*(x-matched_len). With half as prefix match. For IPv6, > > saving is m*60 bits; and for IPv4 saving is m*14 bits. Pick a > > value of m, if what I have mentiond sounds (...) :). Also, I > > have chosen byte-wise matched-len as mentioned in this email > > (http://www1.ietf.org/mail-archive/working-groups/rohc/current > > /msg01884.html) > > > > > > > T6) Any potential gain with IP/AC is not of major > > significance, also > > > considering that IR-CR is already an optimization of the > > > initialization procedure only (see also NT3). > > > > My above comments nullifies this conclusion. If you don't > > agree, please tell me why not. > > > > > > > > Non-technical aspects > > > --------------------- > > > NT1) Motivations for the "field behavior" addressed by > > ROHC-TCP/CR HC > > > has been extensively discussed and agreed. Addressing a > > > different > > > type of behavior must be properly motivated - just like > > > behaviors > > > currently addressed. > > > > Please see my comment under NT3. > > > > > NT2) The fact that some bits are currently used for > > byte-alignment in > > > the TCP IR-CR packet formats is not a motivation for > including > > > IP/AC; > > > > IP/AC is not asking to use any byte-alignment bits. Again, > > you are missing the point and earlier emails from me. I have > > repeated this above. Please let me know what is not clear in > > my statements. > > > > > NT3) Applicability of IP/AC (mobile router and satellite > > links - i.e. > > > not last-link) is limited and not the most expected case; > > > > > > We should not limit our solution for only "one" case, which > > we thought two years ago during the "field behavior" > > discussion. We have missed some case at that time, and now we > > have chance to include them. Why not broaden the solution to > > these likely cases? Especially, when doing so is not costing > > a bit for the previously thought case. In fact, it is saving > > more bits and will make CR more efficient. > > > > I am not suggesting IP/AC, when the ROHC-CR or ROHC-TCP are > > frozen for further changes. I am suggesting them while we are > > discussing and inviting comments on these drafts. I think any > > hesitation based on our previously set mind should be questionable. > > > > > NT4) A requirement regarding IPRs was agreed by the wg > for the TCP > > > solution. I understand the meaning of "non-assertive" > > > (as read from > > > http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft > > > -saifullah-rohc-ip-addr-comp-context-replicat.txt), > > > but the IPR statement still mentions some limitations > > as to the > > > non-assertivness of the IPR being only valid if other > > > companies do > > > not assert ANY patents against Nokia (even patents not > > related to > > > ROHC); > > > > The text "(even patents not related to ROHC)" is not on the > > IPR web-site. It was added by you. I am copying the whole > > text below for the benefit of others: > > > > "This is an update to the earlier Nokia IPR disclosure to > > the subject > draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt > > (submitted on 2.12.2003). > > > > This is to advise the IETF that Nokia has pending unpublished > > patent application > > "Compressing header data" that may relate to the Internet Draft > > submission: IP Address Compression in Context Replication > > (draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt). > > > > Regarding this Internet Draft submission > > draft-saifullah-rohc-ip-addr-comp-context-replicat-00.txt, > > to the extent this submission is included into final IETF > > standard spesification, Nokia agrees > > not to assert those claims in Nokia patents that apply to this > > submission and are technically necessary to implement the IETF > > standard spesification against any other party in respect of its > > implementation of the specification, provided that the > party relying > > on this commitment does not assert its patents against Nokia." > > > > I am not a legal expert, but the above statement read > > perfectly neutral to me. I would encourage other mailing list > > participants also to explain to me why the above statement is > > not neutral. > > > > > > > NT5) The scenarios for motivating the occurence of > > > PREFIX-Match are too > > > weak for including IP/AC in the ROHC-TCP/CR solution; > > > NT6) Points T6) and NT5) are too weak to make IP/AC a core > > > functionality of ROHC-TCP/CR with respect to violating NT4). > > > > > > > Please reconsider NT5 and NT6 based on my above comments. > > > > > Best regards, > > > > > > /Ghyslain > > > > > > > _______________________________________________ > > 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 Dec 18 06:48:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16249 for ; Thu, 18 Dec 2003 06:48: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 1AWwdP-0004rh-Je for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 06:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIBm368018640 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 06:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwdP-0004qZ-7A for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 06:48: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 GAA16223 for ; Thu, 18 Dec 2003 06:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwdL-0002k4-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:47:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwdJ-0002ju-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:47:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwdJ-0002jr-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:47:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwdM-0004qI-Uu; Thu, 18 Dec 2003 06:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwcy-0004pg-T4 for rohc@optimus.ietf.org; Thu, 18 Dec 2003 06:47: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 GAA16154 for ; Thu, 18 Dec 2003 06:47:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwcu-0002hH-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:47:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwcp-0002gE-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:47:32 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AWwcp-0002dV-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:47:27 -0500 Received: from effnet.com ([192.168.101.51]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id hBIAkmqP011358 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 18 Dec 2003 11:46:48 +0100 Message-ID: <3FE193B8.2030005@effnet.com> Date: Thu, 18 Dec 2003 12:47:04 +0100 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] Comments on draft-ietf-rohc-udp-lite-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi! I have looked through the UDP-lite profile draft and have the following comments: * "4.1 design motivations" more or less says that the profile should be as similar as possible to the UDP profile, and then the "arbitrary number of IP headers" are added as in the IP profile. I'm not saying this is wrong, but possibly there should be some text saying that "and also include the improvements to ROHC included in the IP only profile" or something along those lines (Note: I know this is in "Introduction", but that's not really enough). * Since we're adding the arbitrary number of headers, then we should also add the CONTEXT_MEMORY feedback option as in the IP profile. * In 5.3.2, below the picure, it explains the special updating properties of CE(ON) and CE(OFF). I think it should be said here that these two packet types cannot be used to extend R-0 and R1* headers instead of mentioning it in the separate sections for these packets on the next page. It will just lead to confusion the first time reading it. Overall, the document looks good seems to fill its purpose. Rgds, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 18 06:59:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16694 for ; Thu, 18 Dec 2003 06:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwo2-00057Q-Vx for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 06:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIBx25k019670 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 06: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 1AWwo2-00057B-SX for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 06: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 GAA16678 for ; Thu, 18 Dec 2003 06:58:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwny-0003HG-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:58:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwnx-0003H9-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:58:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwnx-0003H6-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 06:58:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwo1-00056w-1i; Thu, 18 Dec 2003 06: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 1AWwn6-00055G-Hx for rohc@optimus.ietf.org; Thu, 18 Dec 2003 06: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 GAA16633 for ; Thu, 18 Dec 2003 06:58:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwn2-0003G3-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwn1-0003Ft-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:58:00 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AWwn1-0003FS-00 for rohc@ietf.org; Thu, 18 Dec 2003 06:57:59 -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 hBIBvnI2026889; Thu, 18 Dec 2003 12:57:50 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Dec 2003 12:57:49 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: Wang Haiguang Cc: rohc@ietf.org Date: Thu, 18 Dec 2003 12:57:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE: Question about the context refreshment Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The compression slow-start as explained in IP-HC is a good example of an implementation strategy for U-mode operation, but in no way mandating anything. /L-E > -----Original Message----- > From: Wang Haiguang [mailto:wanghg@i2r.a-star.edu.sg] > Sent: den 18 december 2003 03:47 > To: Lars-Erik Jonsson (LU/EAB) > Subject: Question about the context refreshment > > > Hi, Erik. > > I have some question about the context refreshment in U-mode > of compressor > as follows. > Could you please try to give me an answer on it? > > In the specification for the compressor state transition > scheme (RFC3095 > 5.3.1.1.1 -- 5.3.1.1.3). > > I saw the periodic context refreshment part refers to the > IPHC (RFC 2507) > 3.3.1-3.3.2, which contains > the compression slow start scheme. > > Is the compression slow start scheme also used in ROHC at the > beginning of a > session? Or just sent > out consectutive IR packets assume k and then the compressor > transit to > higher state, i.e. the SO state > and send out packet with compressed headers. > > I find that compression slow start is also mentioned in the > ROHC TCP draft. > > Best regards. > > Haiguang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 18 07:03:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16832 for ; Thu, 18 Dec 2003 07:03: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 1AWwru-0005En-N3 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 07:03:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIC32O1020127 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 07:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwru-0005EY-J5 for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 07:03: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 HAA16824 for ; Thu, 18 Dec 2003 07:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwrq-0003Nm-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 07:02:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwrp-0003Nf-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 07:02:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwrp-0003Nc-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 07:02:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwrs-0005DQ-Ib; Thu, 18 Dec 2003 07:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwro-0005DB-JP for rohc@optimus.ietf.org; Thu, 18 Dec 2003 07:02:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16821 for ; Thu, 18 Dec 2003 07:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwrk-0003NZ-00 for rohc@ietf.org; Thu, 18 Dec 2003 07:02:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwrj-0003NS-00 for rohc@ietf.org; Thu, 18 Dec 2003 07:02:51 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AWwri-0003NP-00 for rohc@ietf.org; Thu, 18 Dec 2003 07:02:51 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBIC2p8K022767; Thu, 18 Dec 2003 13:02:51 +0100 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Z1FXTRWT; Thu, 18 Dec 2003 13:04:01 +0100 Received: by lms001.lu.erisoft.se id NAA20667; Thu, 18 Dec 2003 13:02:53 +0100 (MET) Message-ID: <3FE19823.D15C11D4@ericsson.com> Date: Thu, 18 Dec 2003 13:05:55 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kristofer Sandlund , rohc@ietf.org Subject: Re: [rohc] Comments on draft-ietf-rohc-udp-lite-01.txt References: <3FE193B8.2030005@effnet.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id hBIC2p8K022767 Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kristofer, Thanks for your review and your comments! I agree with all three comments and will make the appropriate changes to the document, unless I hear objections on the list regarding these comments. I will thus update the design motivations, add the CONTEXT_MEMORY feedback option and clarify the special updating properties of the CE(*) packets, as you suggested. > Overall, the document looks good seems to fill its purpose. Can I conclude from this that you agree with the general approach taken for the profiles for UDP-Lite and the proposed solution? Now that the UDP-Lite draft has been approved by the IESG and is in the RFC queue, I would like to move forward with the ROHC profiles for UDP-Lite. I'd like to invite other people interested in this document to provide feedback to the list (Mark? Richard?). Thanks! Best regards, /Ghyslain Kristofer Sandlund wrote: >=20 > Hi! >=20 > I have looked through the UDP-lite profile draft and have the following= comments: >=20 > * "4.1 design motivations" more or less says that the profile should be= as > similar as possible to the UDP profile, and then the "arbitrary number = of IP > headers" are added as in the IP profile. I'm not saying this is wrong, = but > possibly there should be some text saying that "and also include the > improvements to ROHC included in the IP only profile" or something alon= g those > lines (Note: I know this is in "Introduction", but that's not really en= ough). >=20 > * Since we're adding the arbitrary number of headers, then we should al= so add > the CONTEXT_MEMORY feedback option as in the IP profile. >=20 > * In 5.3.2, below the picure, it explains the special updating properti= es of > CE(ON) and CE(OFF). I think it should be said here that these two packe= t types > cannot be used to extend R-0 and R1* headers instead of mentioning it i= n the > separate sections for these packets on the next page. It will just lead= to > confusion the first time reading it. >=20 > Overall, the document looks good seems to fill its purpose. >=20 > Rgds, > Kristofer Sandlund, Effnet AB >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 18 07:46:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18172 for ; Thu, 18 Dec 2003 07:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxXZ-0007lT-D8 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 07:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBICk5Pm029843 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 07:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxXZ-0007lG-9P for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 07:46: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 HAA18161 for ; Thu, 18 Dec 2003 07:46:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxXY-0004tv-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 07:46:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxXX-0004to-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 07:46:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWxXX-0004tl-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 07:46:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxXW-0007kx-3Q; Thu, 18 Dec 2003 07: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 1AWxXR-0007kQ-4d for rohc@optimus.ietf.org; Thu, 18 Dec 2003 07:45: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 HAA18158 for ; Thu, 18 Dec 2003 07:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxXQ-0004th-00 for rohc@ietf.org; Thu, 18 Dec 2003 07:45:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxXP-0004ta-00 for rohc@ietf.org; Thu, 18 Dec 2003 07:45:56 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AWxXP-0004tX-00 for rohc@ietf.org; Thu, 18 Dec 2003 07:45:55 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBICjr8K000883; Thu, 18 Dec 2003 13:45:54 +0100 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAWKRGSK; Thu, 18 Dec 2003 13:45:51 +0100 Received: by lms001.lu.erisoft.se id NAA21550; Thu, 18 Dec 2003 13:45:54 +0100 (MET) Message-ID: <3FE1A238.77655D4@ericsson.com> Date: Thu, 18 Dec 2003 13:48:56 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kristofer Sandlund , rohc@ietf.org Subject: Re: [rohc] Comments on draft-ietf-rohc-udp-lite-01.txt References: <3FE193B8.2030005@effnet.com> <3FE19823.D15C11D4@ericsson.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id hBICjr8K000883 Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ghyslain Pelletier wrote: > I will thus update the design motivations, add the CONTEXT_MEMORY > feedback option and clarify the special updating properties of the > CE(*) packets, as you suggested. Oups - I did mean "clarify the special updating properties of the CE(ON) and CE(OFF)" only, not CE(*)... /Ghyslain --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 18 09:23:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23055 for ; Thu, 18 Dec 2003 09:23:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz3Q-0004PJ-WB for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 09:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIEN4s1016935 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 09:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz3Q-0004P4-S1 for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 09:23: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 JAA23019 for ; Thu, 18 Dec 2003 09:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz3P-0003Q7-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 09:23:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz3N-0003Pu-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 09:23:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWz3M-0003Pr-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 09:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz3N-0004Nz-Je; Thu, 18 Dec 2003 09:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz2t-0004NQ-0U for rohc@optimus.ietf.org; Thu, 18 Dec 2003 09:22:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23009 for ; Thu, 18 Dec 2003 09:22:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz2r-0003Oz-00 for rohc@ietf.org; Thu, 18 Dec 2003 09:22:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz2q-0003Os-00 for rohc@ietf.org; Thu, 18 Dec 2003 09:22:28 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AWz2p-0003KM-00 for rohc@ietf.org; Thu, 18 Dec 2003 09:22:27 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Dec 2003 14:21:51 -0000 Message-ID: From: "Surtees, Abigail" To: "'Jan Christoffersson (LU/EAB)'" , "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: Thu, 18 Dec 2003 14:21:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=RISK_FREE autolearn=no version=2.60 Hi all, Slightly belatedly, a response about continuous mode. The main question is what is the consensus about what 'continuous mode' actually means? I think there are at least two interpretations. (I also suggest that when we reach consensus, it should be put into the implementer's guide.) 3320 says that you can use SigComp for stream data in one of two ways: "1) The dispatcher collects a complete SigComp message and then invokes the UDVM. The advantage is that, even in implementations that have multiple incoming compressed streams, only one instance of the UDVM is ever required. 2) The dispatcher collects the SigComp header (see Section 7) and invokes the UDVM; the UDVM stays active while the rest of the message arrives. The advantage is that there is no need to buffer up the rest of the message; the message can be decompressed as it arrives, and any decompressed output can be relayed to the application immediately." In general, which of the strategies is used is an implementation choice." I believe that in any event 2) is continuous mode. Because the UDVM persists it requires greater security than TCP alone provides. As stated in 3320 agreement is required between the two endpoints to use continuous mode. Interpretation 1: An endpoint can open a UDVM on receipt of part of a SigComp message over TCP and leave it open until the rest of the message is received. Consequently, the endpoint has to be able to cope with multiple UDVMs running, but other than that everything works in the same way as normal. In what way is the security risk any greater when using this interpretation of continuous mode than when buffering the message first? Interpretation 2: Because the dispatcher can pass the decompressed output straight to the application, more than one SIP message can be put into one SigComp message. In fact, the whole SIP flow could be compressed in one SigComp message as long as there is some way to flush the last few bytes of a SIP message through the connection. Because the UDVM, and consequently its circular buffer persist, there is no need to store and look up state (another reason why greater security is required) and there is no need for the SIP stack to 'authenticate' each message. In fact, SigComp no longer has any concept of an application layer message so authentication of a message no longer has any meaning. To the SIP stack, SigComp looks exactly like TCP. If synchronisation is lost (e.g. decompression failure occurs) then the connection would have to be restarted but this is the same as if synchronisation is lost by the SIP stack. The likelihood of decompression failure occurring is greatly decreased by the fact that there are no state look ups (there's no risk of the state not being present). The 64k uncompressed message limit is to provide security against "generating huge messages to muck up the SIP stack" attacks. If the extra security mechanisms that make continuous mode safe to use can also prevent this attack, then isn't it safe to drop the message limit? Then the whole SIP flow can be compressed by one SigComp message and delivered in small chunks without a message limit size problem. Which (if either) interpretation have other people assumed, or is there another interpretation we haven't considered? On the issue of whether or not use of continuous mode could solve the issue of multiplexing on a TCP connection, I think that if interpretation 1 is the consensus, then as Jan said there are still problems and continuous mode is not the solution. However, if interpretation 2 is the consensus, then as Mark suggested continuous mode could be used (allowable because of the security provided by IPsec) and then there is no need for multiplexing. Best regards, Abbie > -----Original Message----- > From: Jan Christoffersson (LU/EAB) > [mailto:jan.christoffersson@ericsson.com] > Sent: Monday, November 24, 2003 10:13 AM > 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 > > > 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 > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Dec 18 09:31:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23411 for ; Thu, 18 Dec 2003 09:31: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 1AWzB3-0004jN-05 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 09:30:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIEUuAc018179 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 09:30:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzB2-0004j8-TA for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 09:30:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23336 for ; Thu, 18 Dec 2003 09:30:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWzAw-0003mT-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 09:30:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWzAU-0003lK-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 09:30:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWzAU-0003jz-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 09:30:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzAB-0004fm-4R; Thu, 18 Dec 2003 09:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz9z-0004f1-CI for rohc@optimus.ietf.org; Thu, 18 Dec 2003 09:29:51 -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 JAA23290 for ; Thu, 18 Dec 2003 09:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz9i-0003hs-00 for rohc@ietf.org; Thu, 18 Dec 2003 09:29:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz9I-0003h8-00 for rohc@ietf.org; Thu, 18 Dec 2003 09:29:09 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AWz9I-0003eU-00 for rohc@ietf.org; Thu, 18 Dec 2003 09:29:08 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Dec 2003 14:28:27 -0000 Message-ID: From: "Surtees, Abigail" To: rohc@ietf.org Date: Thu, 18 Dec 2003 14:28:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [rohc] SigComp implementer's guide Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi All, I'm intending to revise the implementer's guide before Christmas as it is due to expire on Christmas Day! I propose the following text for section 5.2 based on the email exchange that finished with mail http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01754.html. "5.2 Multiple State Retention Priorities There may be confusion when the same piece of state is created at two different retention priorities. The following clarifies this: The retention priority should be associated with the compartment and not with the piece of state. For example, if endpoint A creates a piece of state with retention priority 1 and endpoint B creates exactly the same state with retention priority 2, there should be one copy (assuming the model of state management suggested in SigComp [1]) of the actual state but each compartment should keep a record of this piece of state with its own priority. (If this does not happen then the state may be kept for longer than A anticipated or less time than B anticipated depending on which priority is used. This could cause Decompression Failure to occur.) If the same piece of state is created within a compartment with a different priority, then one copy of it should be stored with the new priority and it should count only once against SMS. That is, the state creation updates the priority rather than creates a new piece of state." Comments and other issues that should be added would be appreciated. I realise some people are already on their Christmas holidays and so may not see this. The issue of continuous mode (see my other mail about continuous mode/multiplexing issues) is on going, consequently I expect there to be a further revision of the draft, so anything missed now can be added then. I plan to submit the draft on Monday. 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 Thu Dec 18 15:32:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15467 for ; Thu, 18 Dec 2003 15:32:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4oe-0006bk-AD for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 15:32:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIKWCGs025394 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 15:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4oe-0006bV-20 for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 15:32: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 PAA15401 for ; Thu, 18 Dec 2003 15:32:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4oc-00062Y-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 15:32:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4oW-00061R-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 15:32:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX4oV-000613-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 15:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4oT-0006Vl-Ig; Thu, 18 Dec 2003 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4nj-0006Jc-4g for rohc@optimus.ietf.org; Thu, 18 Dec 2003 15:31:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15243; Thu, 18 Dec 2003 15:31:12 -0500 (EST) Message-Id: <200312182031.PAA15243@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, 18 Dec 2003 15:31:12 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-udp-lite-02.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC):Profiles for UDP-Lite Author(s) : G. Pelletier Filename : draft-ietf-rohc-udp-lite-02.txt Pages : 18 Date : 2003-12-18 This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles specified in [RFC-3095] for UDP [RFC-768]. Although both transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because it does not share protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field and as a consequence cannot always be inferred anymore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-udp-lite-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-udp-lite-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-12-18142851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-udp-lite-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-udp-lite-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142851.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 Dec 18 20:41:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05730 for ; Thu, 18 Dec 2003 20:41:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX9da-0006Tp-Nf for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 20:41:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ1f6Cl024903 for rohc-archive@odin.ietf.org; Thu, 18 Dec 2003 20:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX9da-0006Ta-JA for rohc-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 20:41: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 UAA05697 for ; Thu, 18 Dec 2003 20:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX9dV-00071S-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 20:41:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX9dT-00071J-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 20:41:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX9dT-00071G-00 for rohc-web-archive@ietf.org; Thu, 18 Dec 2003 20:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX9dV-0006TJ-9v; Thu, 18 Dec 2003 20: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 1AX9d0-0006SX-Fw for rohc@optimus.ietf.org; Thu, 18 Dec 2003 20:40: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 UAA05686 for ; Thu, 18 Dec 2003 20:40:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX9cy-00070n-00 for rohc@ietf.org; Thu, 18 Dec 2003 20:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX9cx-00070f-00 for rohc@ietf.org; Thu, 18 Dec 2003 20:40:27 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AX9cx-00070b-00 for rohc@ietf.org; Thu, 18 Dec 2003 20:40:27 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX9cx-0006AG-HE; Fri, 19 Dec 2003 01:40:27 +0000 To: rohc@ietf.org Cc: cabo@tzi.org, lars-erik.jonsson@ericsson.com Reply-To: mankin@psg.com Date: Thu, 18 Dec 2003 17:40:25 -0800 From: Allison Mankin Message-Id: Subject: [rohc] IESG Approval of draft-ietf-rohc-ip-only Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 ROHC Folks, Chairs, During the IESG meeting today, draft-ietf-rohc-ip-only-05.txt was approved. An announcement will come out early next week. It is a good, clear spec. The ROHC MIB finished its MIB Doctor expert reviews (which were very detailed), and it is in IETF Last Call, finishing up tomorrow (12/19). I'll put the MIB and the companion Informational, draft-ietf-rohc-terminology-and-examples-02.txt, on the IESG agenda right after the turn of the year. Happy New Year, Allison _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Dec 22 12:49:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26824 for ; Mon, 22 Dec 2003 12:49:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYUAf-0002ZL-2A for rohc-archive@odin.ietf.org; Mon, 22 Dec 2003 12:48:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMHmjK7009871 for rohc-archive@odin.ietf.org; Mon, 22 Dec 2003 12:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYUAe-0002Z8-Sb for rohc-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 12:48: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 MAA26803 for ; Mon, 22 Dec 2003 12:48:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYUAY-0003ej-00 for rohc-web-archive@ietf.org; Mon, 22 Dec 2003 12:48:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYUA7-0003eM-00 for rohc-web-archive@ietf.org; Mon, 22 Dec 2003 12:48:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYUA6-0003dc-00 for rohc-web-archive@ietf.org; Mon, 22 Dec 2003 12:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYU9w-0002Vw-I2; Mon, 22 Dec 2003 12:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYU9k-0002VZ-Ih for rohc@optimus.ietf.org; Mon, 22 Dec 2003 12:47:53 -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 MAA26753 for ; Mon, 22 Dec 2003 12:47:44 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AYU8u-0000El-KT; Mon, 22 Dec 2003 12:46:56 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 22 Dec 2003 12:46:56 -0500 Subject: [rohc] Protocol Action: '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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved following document: - 'RObust Header Compression (ROHC): A Compression Profile for IP ' as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document defines one additional compression profile for the RObust Header Compression (ROHC) framework, as defined by RFC 3095. In RFC 3095, profiles are specified for compression of IP/UDP, IP/UDP/RTP, IP/ESP, as well as for uncompressed ROHC transmission. However, a compression profile for IP only was omitted in RFC 3095, and this document contributes with that missing piece. The profile is defined to require minimal modifications to existing ROHC code base, although it does provide some minor but useful enhancements and corrections, compared to the RFC 3095 profiles. Working Group Summary There was strong consensus in the working group to get this profile published, as it was seen to become an important complement to RFC 3095. Protocol Quality Allison Mankin reviewed the document for the IESG. In the working group, the document was carefully reviewed by several implementers of RFC 3095, and the working group and IETF Last Calls did not raise any issues. RFC Editor Note Re-name the References - Normative References _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Dec 23 15:40:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08763 for ; Tue, 23 Dec 2003 15:40:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtJf-0008U2-2M for rohc-archive@odin.ietf.org; Tue, 23 Dec 2003 15:39:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNKdhQR032606 for rohc-archive@odin.ietf.org; Tue, 23 Dec 2003 15:39:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtJe-0008Tp-Vh for rohc-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 15:39: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 PAA08666 for ; Tue, 23 Dec 2003 15:39:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtJd-00023w-00 for rohc-web-archive@ietf.org; Tue, 23 Dec 2003 15:39:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtHq-0001yd-00 for rohc-web-archive@ietf.org; Tue, 23 Dec 2003 15:37:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYtG8-0001ua-00 for rohc-web-archive@ietf.org; Tue, 23 Dec 2003 15:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtG8-0007iE-74; Tue, 23 Dec 2003 15: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 1AYtFm-0007fh-AB for rohc@optimus.ietf.org; Tue, 23 Dec 2003 15:35:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08116; Tue, 23 Dec 2003 15:35:39 -0500 (EST) Message-Id: <200312232035.PAA08116@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: Tue, 23 Dec 2003 15:35:39 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-impl-guide-02.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Implementer's Guide for SigComp Author(s) : A. Surtees Filename : draft-ietf-rohc-sigcomp-impl-guide-02.txt Pages : 9 Date : 2003-12-23 This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-impl-guide-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-12-23153240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-impl-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153240.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc