From rohc-bounces@ietf.org Tue Jan 03 04:38:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EticT-0004zW-7G; Tue, 03 Jan 2006 04:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EticR-0004zR-RO for rohc@megatron.ietf.org; Tue, 03 Jan 2006 04:38:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27719 for ; Tue, 3 Jan 2006 04:37:02 -0500 (EST) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etihf-0003qZ-Bv for rohc@ietf.org; Tue, 03 Jan 2006 04:43:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E1DEB90089 for ; Tue, 3 Jan 2006 04:37:59 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15826-03 for ; Tue, 3 Jan 2006 04:37:58 -0500 (EST) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 3 Jan 2006 04:37:58 -0500 (EST) Received: from EXCHINDIA2.starentnetworks.com ([10.4.0.4]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Jan 2006 04:37:58 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jan 2006 15:07:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: Thread-Topic: ROHC: CSRC Thread-Index: AcYQSV3rPci89iJSQJCn01C2W3JKEQ== From: "Sarkar, Biplab" To: X-OriginalArrivalTime: 03 Jan 2006 09:37:58.0487 (UTC) FILETIME=[61B9EE70:01C61049] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Subject: [rohc] ROHC: CSRC X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1077271987==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1077271987== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61049.5E4C304A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61049.5E4C304A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I have a query. =20 Why do we have CSRC list to be a part of CRC-STATIC calculations [RFC3095: 5.7.7.6]? I thought it should have been in CRC-DYNAMIC group. =20 Thanks Biplab =20 ++++++++++++++++++++++++++++++++ Biplab Sarkar Starent Networks, Bangalore ++++++++++++++++++++++++++++++++ =20 ------_=_NextPart_001_01C61049.5E4C304A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I have = a query.

 

Why do = we have CSRC list to be a part of CRC-STATIC calculations [RFC3095: 5.7.7.6]? =  I thought it should have been in CRC-DYNAMIC group. =

 

Thanks

Biplab

 

++++++++++++++++++++++++++++++++

Biplab = Sarkar

Starent Networks, Bangalore

++++++++++++++++++++++++++++++++

 

------_=_NextPart_001_01C61049.5E4C304A-- --===============1077271987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1077271987==-- From rohc-bounces@ietf.org Wed Jan 04 12:59:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCv1-00039z-B8; Wed, 04 Jan 2006 12:59:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCuz-00039m-26 for rohc@megatron.ietf.org; Wed, 04 Jan 2006 12:59:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07166 for ; Wed, 4 Jan 2006 12:58:10 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuD0Q-0002W8-MF for rohc@ietf.org; Wed, 04 Jan 2006 13:05:08 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5B5373B7; Wed, 4 Jan 2006 18:59:16 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 18:59:16 +0100 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 18:59:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC: CSRC Date: Wed, 4 Jan 2006 18:59:15 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502104B09@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] ROHC: CSRC Thread-Index: AcYQSV3rPci89iJSQJCn01C2W3JKEQBDmE4w From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Sarkar, Biplab" , X-OriginalArrivalTime: 04 Jan 2006 17:59:16.0048 (UTC) FILETIME=[93C34500:01C61158] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org According to RFC 3095, it is part of CRC-STATIC, correct. The only fields part of CRC_DYNAMIC are those generally expected to change on a packet-to-packet basis, i.e.: - Total Length, Identification, Header Checksum - Length field, Checksum=20 - M-bit, sequence number field, and timestamp=20 BR /L-E ----Original Message---- From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf Of Sarkar, Biplab Sent: den 3 januari 2006 10:38 To: rohc@ietf.org Subject: [rohc] ROHC: CSRC > All, >=20 >=20 >=20 > I have a query. >=20 >=20 >=20 > Why do we have CSRC list to be a part of CRC-STATIC > calculations [RFC3095: 5.7.7.6]? I thought it should have been in > CRC-DYNAMIC group.=20 >=20 >=20 >=20 > Thanks >=20 > Biplab >=20 >=20 >=20 > ++++++++++++++++++++++++++++++++ >=20 > Biplab Sarkar >=20 > Starent Networks, Bangalore >=20 > ++++++++++++++++++++++++++++++++ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 04 15:50:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFaf-0002Fa-48; Wed, 04 Jan 2006 15:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFaB-0001tU-4a; Wed, 04 Jan 2006 15:50:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24135; Wed, 4 Jan 2006 15:48:48 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFfg-0008LN-I8; Wed, 04 Jan 2006 15:55:49 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EuFa5-00080p-KG; Wed, 04 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-tcp-11.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org --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): A Profile for TCP/IP (ROHC-TCP) Author(s) : G. Pelletier, et al. Filename : draft-ietf-rohc-tcp-11.txt Pages : 108 Date : 2006-1-4 Existing TCP/IP header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. In addition, existing schemes have not addressed how to compress TCP options such as SACK (Selective Acknowledgements) and Timestamps. This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-tcp-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-tcp-11.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: <2006-1-4114451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-tcp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-tcp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-4114451.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Thu Jan 05 01:16:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuOQP-000894-Hw; Thu, 05 Jan 2006 01:16:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuOQJ-00087S-7U for rohc@megatron.ietf.org; Thu, 05 Jan 2006 01:16:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28385 for ; Thu, 5 Jan 2006 01:15:15 -0500 (EST) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuOVt-0004aA-9I for rohc@ietf.org; Thu, 05 Jan 2006 01:22:20 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 66C879003B for ; Thu, 5 Jan 2006 01:16:11 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25021-01 for ; Thu, 5 Jan 2006 01:16:10 -0500 (EST) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 5 Jan 2006 01:16:09 -0500 (EST) Received: from EXCHINDIA2.starentnetworks.com ([10.4.0.4]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Jan 2006 01:15:49 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 5 Jan 2006 11:41:13 +0530 Message-ID: Thread-Topic: Timer-based compression Thread-Index: AcYRvtQErm47Zh5ySeyn7C19jam1Wg== From: "Sarkar, Biplab" To: X-OriginalArrivalTime: 05 Jan 2006 06:15:49.0727 (UTC) FILETIME=[793F86F0:01C611BF] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Subject: [rohc] Timer-based compression X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0817161414==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============0817161414== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C611BE.D47EB06E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C611BE.D47EB06E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I have a query. =20 How does the decompressor know "from" which packet onward it would be getting packets encoded with timer-based-compression? Since the ACK from the decompressor which carries the CLOCK option might take some time to reach and get processed at the compressor; is there any way for the decompressor to know when to expect packets to be encoded with the timer-based compression method. =20 Thanks Biplab =20 ++++++++++++++++++++++++++++++++ Biplab Sarkar Starent Networks, Bangalore ++++++++++++++++++++++++++++++++ =20 ------_=_NextPart_001_01C611BE.D47EB06E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I have = a query.

 

How = does the decompressor know “from” which packet onward it would be = getting packets encoded with timer-based-compression? Since the ACK from the decompressor which carries the CLOCK option might take some time to = reach and get processed at the compressor; is there any way for the decompressor = to know when to expect packets to be encoded with the timer-based compression = method.

 

Thanks

Biplab

 

++++++++++++++++++++++++++++++++

Biplab = Sarkar

Starent Networks, Bangalore

++++++++++++++++++++++++++++++++

 

------_=_NextPart_001_01C611BE.D47EB06E-- --===============0817161414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0817161414==-- From rohc-bounces@ietf.org Thu Jan 05 02:03:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuP9c-0008IN-MK; Thu, 05 Jan 2006 02:03:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuP9b-0008II-5k for rohc@megatron.ietf.org; Thu, 05 Jan 2006 02:03:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03324 for ; Thu, 5 Jan 2006 02:01:58 -0500 (EST) Received: from mail46.messagelabs.com ([216.82.241.227]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuPF8-0006Ap-RV for rohc@ietf.org; Thu, 05 Jan 2006 02:09:04 -0500 X-VirusChecked: Checked X-Env-Sender: Kavitha.KR@lntinfotech.com X-Msg-Ref: server-6.tower-46.messagelabs.com!1136444570!17724924!2 X-StarScan-Version: 5.5.9.1; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 3420 invoked from network); 5 Jan 2006 07:02:53 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-6.tower-46.messagelabs.com with SMTP; 5 Jan 2006 07:02:53 -0000 Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006010512325014-11717 ; Thu, 5 Jan 2006 12:32:50 +0530 In-Reply-To: To: rohc@ietf.org Subject: Re: [rohc] Timer-based compression MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Kavitha KR Date: Thu, 5 Jan 2006 12:36:44 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 12:36:44 PM, Serialize complete at 01/05/2006 12:36:44 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 12:32:50 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 12:32:53 PM, Serialize complete at 01/05/2006 12:32:53 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1219869429==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multipart message in MIME format. --===============1219869429== Content-Type: multipart/alternative; boundary="=_alternative 0026BB58652570ED_=" This is a multipart message in MIME format. --=_alternative 0026BB58652570ED_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksCgpDb21wcmVzc29yIGNhbiBiZSBtYWRlIHRvIHNlbmQgYW4gVU9SLTIgcGFja2V0IHdpdGgg ZXh0LTMgb3IgSVIvSVItRFlOIApwYWNrZXQgd2l0aCBUSVM9MSBhbmQgVElNRV9TVFJJREUgdmFs dWUgYmVmb3JlIGl0IGJlZ2lucyB0byBkbyBUaW1lciBiYXNlZCAKQ29tcHJlc3Npb24gb2YgVFMu ICBJdCBpcyBhIHdheSB0byBpbmRpY2F0ZSB0aW1lci1iYXNlZCBjb21wcmVzc2lvbiBvZiBUUyAK dG8gdGhlIGRlY29tcHJlc3Nvci4gCihSZWZlciBSRkMgMzA5NSBTZWMgNS43LjUgIEV4dGVuc2lv biBGb3JtYXRzKQoKS2F2aXRoYSBLLlIuLApMJlQgSW5mb3RlY2gsCkJhbmdhbG9yZS4KCiggKSBM JlQgSW5mb3RlY2ggUHJvcHJpZXRhcnkgJiBDb25maWRlbnRpYWwKKCApIEwmVCBJbmZvdGVjaCBD b25maWRlbnRpYWwKKCkgTCZUIEluZm90ZWNoIEludGVybmFsIFVzZSBvbmx5CigrKSBHZW5lcmFs IEJ1c2luZXNzIEluZm9ybWF0aW9uCgoKCiJTYXJrYXIsIEJpcGxhYiIgPGJzYXJrYXJAc3RhcmVu dG5ldHdvcmtzLmNvbT4gClNlbnQgYnk6IHJvaGMtYm91bmNlc0BpZXRmLm9yZwowMS8wNS8yMDA2 IDExOjQxIEFNCgpUbwo8cm9oY0BpZXRmLm9yZz4KY2MKClN1YmplY3QKW3JvaGNdIFRpbWVyLWJh c2VkIGNvbXByZXNzaW9uCgoKCgoKCkFsbCwKIApJIGhhdmUgYSBxdWVyeS4KIApIb3cgZG9lcyB0 aGUgZGVjb21wcmVzc29yIGtub3cg4oCcZnJvbeKAnSB3aGljaCBwYWNrZXQgb253YXJkIGl0IHdv dWxkIGJlIApnZXR0aW5nIHBhY2tldHMgZW5jb2RlZCB3aXRoIHRpbWVyLWJhc2VkLWNvbXByZXNz aW9uPyBTaW5jZSB0aGUgQUNLIGZyb20gCnRoZSBkZWNvbXByZXNzb3Igd2hpY2ggY2FycmllcyB0 aGUgQ0xPQ0sgb3B0aW9uIG1pZ2h0IHRha2Ugc29tZSB0aW1lIHRvIApyZWFjaCBhbmQgZ2V0IHBy b2Nlc3NlZCBhdCB0aGUgY29tcHJlc3NvcjsgaXMgdGhlcmUgYW55IHdheSBmb3IgdGhlIApkZWNv bXByZXNzb3IgdG8ga25vdyB3aGVuIHRvIGV4cGVjdCBwYWNrZXRzIHRvIGJlIGVuY29kZWQgd2l0 aCB0aGUgCnRpbWVyLWJhc2VkIGNvbXByZXNzaW9uIG1ldGhvZC4KIApUaGFua3MKQmlwbGFiCiAK KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKQmlwbGFiIFNhcmthcgpTdGFyZW50IE5l dHdvcmtzLCBCYW5nYWxvcmUKKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIAoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpSb2hjIG1haWxpbmcgbGlzdApSb2hjQGlldGYub3JnCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3JvaGMKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= --=_alternative 0026BB58652570ED_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGksPC9mb250Pgo8YnI+Cjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q29tcHJlc3NvciBjYW4gYmUgbWFkZSB0byBz ZW5kIGFuIFVPUi0yCnBhY2tldCB3aXRoIGV4dC0zIG9yIElSL0lSLURZTiBwYWNrZXQgd2l0aCBU SVM9MSBhbmQgVElNRV9TVFJJREUgdmFsdWUKYmVmb3JlIGl0IGJlZ2lucyB0byBkbyBUaW1lciBi YXNlZCBDb21wcmVzc2lvbiBvZiBUUy4gJm5ic3A7SXQgaXMgYSB3YXkKdG8gaW5kaWNhdGUgdGlt ZXItYmFzZWQgY29tcHJlc3Npb24gb2YgVFMgdG8gdGhlIGRlY29tcHJlc3Nvci4gPC9mb250Pgo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPihSZWZlciBSRkMgMzA5NSBTZWMgNS43 LjUgJm5ic3A7RXh0ZW5zaW9uCkZvcm1hdHMpPC9mb250Pgo8YnI+Cjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+S2F2aXRoYSBLLlIuLDxicj4KTCZhbXA7VCBJbmZvdGVjaCw8YnI+ CkJhbmdhbG9yZS48YnI+Cjxicj4KKCApIEwmYW1wO1QgSW5mb3RlY2ggUHJvcHJpZXRhcnkgJmFt cDsgQ29uZmlkZW50aWFsPGJyPgooICkgTCZhbXA7VCBJbmZvdGVjaCBDb25maWRlbnRpYWw8YnI+ CigpIEwmYW1wO1QgSW5mb3RlY2ggSW50ZXJuYWwgVXNlIG9ubHk8YnI+CigrKSBHZW5lcmFsIEJ1 c2luZXNzIEluZm9ybWF0aW9uPC9mb250Pgo8YnI+Cjxicj4KPGJyPgo8dGFibGUgd2lkdGg9MTAw JT4KPHRyIHZhbGlnbj10b3A+Cjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPiZxdW90O1NhcmthciwgQmlwbGFiJnF1b3Q7CiZsdDtic2Fya2FyQHN0YXJlbnRu ZXR3b3Jrcy5jb20mZ3Q7PC9iPiA8L2ZvbnQ+Cjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+U2VudCBieTogcm9oYy1ib3VuY2VzQGlldGYub3JnPC9mb250Pgo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MDEvMDUvMjAwNiAxMTo0MSBBTTwvZm9udD4KPHRkIHdpZHRo PTU5JT4KPHRhYmxlIHdpZHRoPTEwMCU+Cjx0ciB2YWxpZ249dG9wPgo8dGQ+CjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pgo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtyb2hjQGlldGYub3JnJmd0OzwvZm9u dD4KPHRyIHZhbGlnbj10b3A+Cjx0ZD4KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+Cjx0ZD4KPHRyIHZhbGlnbj10b3A+Cjx0ZD4K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwv Zm9udD48L2Rpdj4KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bcm9oY10gVGlt ZXItYmFzZWQgY29tcHJlc3Npb248L2ZvbnQ+PC90YWJsZT4KPGJyPgo8dGFibGU+Cjx0ciB2YWxp Z249dG9wPgo8dGQ+Cjx0ZD48L3RhYmxlPgo8YnI+PC90YWJsZT4KPGJyPgo8YnI+Cjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj5BbGwsPC9mb250Pgo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7 PC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBN UyI+SSBoYXZlIGEgcXVlcnkuPC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAg ZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBNUyI+SG93IGRvZXMgdGhlIGRlY29tcHJlc3Nvcgpr bm93IOKAnGZyb23igJ0gd2hpY2ggcGFja2V0IG9ud2FyZCBpdCB3b3VsZCBiZSBnZXR0aW5nIHBh Y2tldHMgZW5jb2RlZCB3aXRoCnRpbWVyLWJhc2VkLWNvbXByZXNzaW9uPyBTaW5jZSB0aGUgQUNL IGZyb20gdGhlIGRlY29tcHJlc3NvciB3aGljaCBjYXJyaWVzCnRoZSBDTE9DSyBvcHRpb24gbWln aHQgdGFrZSBzb21lIHRpbWUgdG8gcmVhY2ggYW5kIGdldCBwcm9jZXNzZWQgYXQgdGhlCmNvbXBy ZXNzb3I7IGlzIHRoZXJlIGFueSB3YXkgZm9yIHRoZSBkZWNvbXByZXNzb3IgdG8ga25vdyB3aGVu IHRvIGV4cGVjdApwYWNrZXRzIHRvIGJlIGVuY29kZWQgd2l0aCB0aGUgdGltZXItYmFzZWQgY29t cHJlc3Npb24gbWV0aG9kLjwvZm9udD4KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZh Y2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwOzwvZm9udD4KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPlRoYW5rczwvZm9udD4KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPkJpcGxhYjwvZm9udD4KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwOzwvZm9u dD4KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxi PisrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrPC9iPjwvZm9udD4KPGJyPjxmb250IHNp emU9MSBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxiPkJpcGxhYiBTYXJrYXI8 L2I+PC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2Fu cyBNUyI+PGI+U3RhcmVudCBOZXR3b3JrcywKQmFuZ2Fsb3JlPC9iPjwvZm9udD4KPGJyPjxmb250 IHNpemU9MSBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxiPisrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrPC9iPjwvZm9udD4KPGJyPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4KPHA+PGZvbnQgc2l6ZT0zPjxicj4KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPgpSb2hjIG1haWxpbmcgbGlzdDxicj4KUm9oY0BpZXRm Lm9yZzxicj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9oYzxicj4K PC90dD48L2ZvbnQ+CjxwPgoKPEJSPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPgoK --=_alternative 0026BB58652570ED_=-- --===============1219869429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1219869429==-- From rohc-bounces@ietf.org Thu Jan 05 02:25:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuPVH-00070a-55; Thu, 05 Jan 2006 02:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuPVC-00070F-UM for rohc@megatron.ietf.org; Thu, 05 Jan 2006 02:25:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05321 for ; Thu, 5 Jan 2006 02:24:23 -0500 (EST) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuPaq-0006tX-7i for rohc@ietf.org; Thu, 05 Jan 2006 02:31:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id F220C90033 for ; Thu, 5 Jan 2006 02:25:28 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26021-04 for ; Thu, 5 Jan 2006 02:25:25 -0500 (EST) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 5 Jan 2006 02:25:25 -0500 (EST) Received: from EXCHINDIA2.starentnetworks.com ([10.4.0.4]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Jan 2006 02:25:24 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] Timer-based compression X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 5 Jan 2006 12:55:18 +0530 Message-ID: Thread-Topic: [rohc] Timer-based compression Thread-Index: AcYRxpaMCe1l/DcaTheVomAssSSmWgAACZyA From: "Sarkar, Biplab" To: "Kavitha KR" X-OriginalArrivalTime: 05 Jan 2006 07:25:24.0939 (UTC) FILETIME=[31DE51B0:01C611C9] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.2 (/) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1264590571==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1264590571== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C611C9.2E41B196" This is a multi-part message in MIME format. ------_=_NextPart_001_01C611C9.2E41B196 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kavitha, =20 I believe with the UOR-2+ext-3 the compressor says that it "can" support "timer-based" compression. If the decompressor supports this, it can send an ACK with the CLOCK option. Once the compressor gets the CLOCK-opt from the decompressor it can change to the "timer-based" compression. But it doesn't let the decompressor know precisely when to start expecting packets compressed with "timer-based" compression. There has to be some way to tell the decompressor that the current packet is compressed with the "timer-based" compression algo. I don't see any flags for this in the RFC. One has to consider the number of packets on transit before deciding to change the compression algorithm after the initial negotiation.=20 =20 Thanks Biplab =20 _____ =20 From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM To: rohc@ietf.org Subject: Re: [rohc] Timer-based compression =20 Hi,=20 Compressor can be made to send an UOR-2 packet with ext-3 or IR/IR-DYN packet with TIS=3D1 and TIME_STRIDE value before it begins to do Timer based Compression of TS. It is a way to indicate timer-based compression of TS to the decompressor.=20 (Refer RFC 3095 Sec 5.7.5 Extension Formats)=20 Kavitha K.R., L&T Infotech, Bangalore. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential () L&T Infotech Internal Use only (+) General Business Information=20 "Sarkar, Biplab" =20 Sent by: rohc-bounces@ietf.org=20 01/05/2006 11:41 AM=20 To =20 cc =20 Subject [rohc] Timer-based compression =20 =20 =20 All,=20 =20 I have a query.=20 =20 How does the decompressor know "from" which packet onward it would be getting packets encoded with timer-based-compression? Since the ACK from the decompressor which carries the CLOCK option might take some time to reach and get processed at the compressor; is there any way for the decompressor to know when to expect packets to be encoded with the timer-based compression method.=20 =20 Thanks=20 Biplab=20 =20 ++++++++++++++++++++++++++++++++=20 Biplab Sarkar=20 Starent Networks, Bangalore=20 ++++++++++++++++++++++++++++++++=20 =20 ________________________________________________________________________ _____________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ______________________________________________________________________ ------_=_NextPart_001_01C611C9.2E41B196 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Kavitha,

 

I = believe with the UOR-2+ext-3 the compressor says that it “can” support = “timer-based” compression. If the decompressor supports this, it can send an ACK with = the CLOCK option. Once the compressor gets the CLOCK-opt from the = decompressor it can change to the “timer-based” compression. But it = doesn’t let the decompressor know precisely when to start expecting packets = compressed with “timer-based” compression.  There has to be some way to = tell the decompressor that the current packet is compressed with the = “timer-based” compression algo.  I don’t see any flags for this in the RFC. = One has to consider the number of packets on transit before deciding to = change the compression algorithm after the initial negotiation. =

 

Thanks

Biplab

 

From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf Of Kavitha KR
Sent: Thursday, January = 05, 2006 12:37 PM
To: rohc@ietf.org
Subject: Re: [rohc] = Timer-based compression

 


Hi,

Compressor can be made to send an UOR-2 packet with ext-3 or IR/IR-DYN packet with = TIS=3D1 and TIME_STRIDE value before it begins to do Timer based Compression of = TS.  It is a way to indicate timer-based compression of TS to the decompressor. =
(Refer RFC 3095 Sec 5.7.5  Extension Formats)

Kavitha K.R.,
L&T Infotech,
Bangalore.

( ) L&T Infotech Proprietary & Confidential
( ) L&T Infotech Confidential
() L&T Infotech Internal Use only
(+) General Business Information

"Sarkar, = Biplab" <bsarkar@starentnetworks.com>
Sent by: rohc-bounces@ietf.org

01/05/2006 11:41 AM

To

<rohc@ietf.org> =

cc

 

Subject

[rohc] Timer-based = compression

 

 

 




All,
 
I have a query. =
 
How does the decompressor know “from” which packet onward it would be getting packets = encoded with timer-based-compression? Since the ACK from the decompressor which = carries the CLOCK option might take some time to reach and get processed at the = compressor; is there any way for the decompressor to know when to expect packets to = be encoded with the timer-based compression method.
 
Thanks
Biplab
 
++++++++++++++++++++++++++++++++<= /font>
Biplab = Sarkar
Starent = Networks, Bangalore
++++++++++++++++++++++++++++++++<= /font>
 


____________________________________________________________________________________________________________________= _
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


______________________________________________________________________

------_=_NextPart_001_01C611C9.2E41B196-- --===============1264590571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1264590571==-- From rohc-bounces@ietf.org Thu Jan 05 02:58:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQ1D-0000Pl-3Q; Thu, 05 Jan 2006 02:58:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQ19-0000Or-Md for rohc@megatron.ietf.org; Thu, 05 Jan 2006 02:58:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08003 for ; Thu, 5 Jan 2006 02:57:23 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuQ6h-0007pk-HO for rohc@ietf.org; Thu, 05 Jan 2006 03:04:30 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 95EE5579; Thu, 5 Jan 2006 08:58:21 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 08:58:21 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 08:58:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Timer-based compression Date: Thu, 5 Jan 2006 08:56:06 +0100 Message-ID: Thread-Topic: [rohc] Timer-based compression Thread-Index: AcYRxpaMCe1l/DcaTheVomAssSSmWgAACZyAAAE4ibA= From: "Kristofer Sandlund \(LU/EAB\)" To: "Sarkar, Biplab" , "Kavitha KR" X-OriginalArrivalTime: 05 Jan 2006 07:58:21.0073 (UTC) FILETIME=[CBBC7010:01C611CD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Hi, Implementer's guide section 4.3: Before timer-based compression can be used, the decompressor will have to inform the compressor (on a per-channel basis) about its clock resolution. Further, the compressor has to send (on a per- context basis) a non-zero TIME_STRIDE to the decompressor. When the compressor is confident that the decompressor has received the TIME_STRIDE value, it can switch to timer-based compression. During this transition from window-based compression to timer-based compression, it is necessary that the compressor keep k large enough to cover both interpretation intervals.=20 So the procedure is: 0) TIME_STRIDE starts out as zero 1) CLOCK option is sent by decompressor and received by compressor 2) Compressor decides that it wants to use timer-based compression. If so, the compressor sends a non-zero TIME_STRIDE 3) Compressor repeats time-stride until it is _confident_ that the decompressor has correctly received the new TIME_STRIDE. Note that these packet are already encoded with timer-based compression since they contain a time-stride that is non-zero. 4) All packets sent after this that contain an encoded timestamp are assumed to be using timer-based compression. The timer-based compression initialization seems to be the most frequent question on this list, but I don't know how to improve the text in the=20 impl-guide any further. I thought it was quite clear now, but obviously=20 it still isn't good enough. Do you have any suggestions on how to=20 improve it further? BR, Kristofer rohc-bounces@ietf.org wrote: > Hi Kavitha, >=20 >=20 >=20 > I believe with the UOR-2+ext-3 the compressor says that it > "can" support "timer-based" compression. If the decompressor > supports this, it can send an ACK with the CLOCK option. Once > the compressor gets the CLOCK-opt from the decompressor it > can change to the "timer-based" compression. But it doesn't > let the decompressor know precisely when to start expecting > packets compressed with "timer-based" compression. There has > to be some way to tell the decompressor that the current > packet is compressed with the "timer-based" compression algo. > I don't see any flags for this in the RFC. One has to > consider the number of packets on transit before deciding to > change the compression algorithm after the initial negotiation. >=20 >=20 >=20 > Thanks >=20 > Biplab >=20 >=20 >=20 > ________________________________ >=20 > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf > Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM > To: rohc@ietf.org > Subject: Re: [rohc] Timer-based compression >=20 >=20 >=20 >=20 > Hi, >=20 > Compressor can be made to send an UOR-2 packet with ext-3 or > IR/IR-DYN packet with TIS=3D1 and TIME_STRIDE value before it > begins to do Timer based Compression of TS. It is a way to > indicate timer-based compression of TS to the decompressor. > (Refer RFC 3095 Sec 5.7.5 Extension Formats) >=20 > Kavitha K.R., > L&T Infotech, > Bangalore. >=20 > ( ) L&T Infotech Proprietary & Confidential > ( ) L&T Infotech Confidential > () L&T Infotech Internal Use only > (+) General Business Information >=20 >=20 >=20 > "Sarkar, Biplab" > Sent by: rohc-bounces@ietf.org >=20 > 01/05/2006 11:41 AM >=20 > To >=20 > >=20 > cc >=20 >=20 >=20 > Subject >=20 > [rohc] Timer-based compression >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > All, >=20 > I have a query. >=20 > How does the decompressor know "from" which packet onward it > would be getting packets encoded with > timer-based-compression? Since the ACK from the decompressor > which carries the CLOCK option might take some time to reach > and get processed at the compressor; is there any way for the > decompressor to know when to expect packets to be encoded > with the timer-based compression method. >=20 > Thanks > Biplab >=20 > ++++++++++++++++++++++++++++++++ > Biplab Sarkar > Starent Networks, Bangalore > ++++++++++++++++++++++++++++++++ >=20 >=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 rohc-bounces@ietf.org Thu Jan 05 03:05:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQ7e-0002wq-5x; Thu, 05 Jan 2006 03:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQ7b-0002t6-OZ for rohc@megatron.ietf.org; Thu, 05 Jan 2006 03:05:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08903 for ; Thu, 5 Jan 2006 03:04:03 -0500 (EST) Received: from mail42.messagelabs.com ([216.82.244.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuQDF-00085K-T8 for rohc@ietf.org; Thu, 05 Jan 2006 03:11:10 -0500 X-VirusChecked: Checked X-Env-Sender: Kavitha.KR@lntinfotech.com X-Msg-Ref: server-23.tower-42.messagelabs.com!1136448304!20120059!2 X-StarScan-Version: 5.5.9.1; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 4606 invoked from network); 5 Jan 2006 08:05:07 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-23.tower-42.messagelabs.com with SMTP; 5 Jan 2006 08:05:07 -0000 Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006010513350418-12016 ; Thu, 5 Jan 2006 13:35:04 +0530 In-Reply-To: To: rohc@ietf.org Subject: RE: [rohc] Timer-based compression MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Kavitha KR Date: Thu, 5 Jan 2006 13:38:58 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 01:38:58 PM, Serialize complete at 01/05/2006 01:38:58 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 01:35:04 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 01:35:07 PM, Serialize complete at 01/05/2006 01:35:07 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0932516239==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multipart message in MIME format. --===============0932516239== Content-Type: multipart/alternative; boundary="=_alternative 002C6E02652570ED_=" This is a multipart message in MIME format. --=_alternative 002C6E02652570ED_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQmlwbGFiLAoKVGhlIGV4cGxhbmF0aW9uIGdpdmVuIGZvciBUSU1FX1NUUklERSBmaWVsZCBp biAiU2VjIDUuNy41LUV4dGVuc2lvbiAKRm9ybWF0cy1SVFAgaGVhZGVyIGZsYWdzIGFuZCBmaWVs ZHMiIGlzIHRoaXM6CgpUSU1FX1NUUklERTogClByZWRpY3RlZCB0aW1lIGludGVydmFsIGluIG1p bGxpc2Vjb25kcyBiZXR3ZWVuCmNoYW5nZXMgaW4gdGhlIFJUUCBUaW1lc3RhbXAuIEFsc28gYW4g aW5kaWNhdGlvbiB0aGF0IHRoZQpjb21wcmVzc29yIGRlc2lyZXMgdG8gcGVyZm9ybSB0aW1lci1i YXNlZCBjb21wcmVzc2lvbiBvZiB0aGUgUlRQCgpJdCBzZWVtcyBzZW5kaW5nIG9mIFRJTUVfU1RS SURFIGZpZWxkIGJ5IHRoZSBjb21wcmVzc29yIG1lYW5zIHRoYXQgaXQgCiJhY3R1YWxseSIgd2Fu dHMgdG8gcGVyZm9ybSBUaW1lciBCYXNlZCBDb21wcmVzc2lvbiBhbmQgbm90IGEgCm1lcmUgImNh cGFiaWxpdHkgaW5kaWNhdGlvbiIuCgpCUiwKS2F2aXRoYSBLLlIuLApMJlQgSW5mb3RlY2gsCkJh bmdhbG9yZS4KCiggKSBMJlQgSW5mb3RlY2ggUHJvcHJpZXRhcnkgJiBDb25maWRlbnRpYWwKKCAp IEwmVCBJbmZvdGVjaCBDb25maWRlbnRpYWwKKCkgTCZUIEluZm90ZWNoIEludGVybmFsIFVzZSBv bmx5CigrICkgR2VuZXJhbCBCdXNpbmVzcyBJbmZvcm1hdGlvbgoKCgoKIlNhcmthciwgQmlwbGFi IiA8YnNhcmthckBzdGFyZW50bmV0d29ya3MuY29tPiAKMDEvMDUvMjAwNiAxMjo1NSBQTQoKVG8K Ikthdml0aGEgS1IiIDxLYXZpdGhhLktSQGxudGluZm90ZWNoLmNvbT4KY2MKPHJvaGNAaWV0Zi5v cmc+ClN1YmplY3QKUkU6IFtyb2hjXSBUaW1lci1iYXNlZCBjb21wcmVzc2lvbgoKCgoKCgpIaSBL YXZpdGhhLAogCkkgYmVsaWV2ZSB3aXRoIHRoZSBVT1ItMitleHQtMyB0aGUgY29tcHJlc3NvciBz YXlzIHRoYXQgaXQg4oCcY2Fu4oCdIHN1cHBvcnQgCuKAnHRpbWVyLWJhc2Vk4oCdIGNvbXByZXNz aW9uLiBJZiB0aGUgZGVjb21wcmVzc29yIHN1cHBvcnRzIHRoaXMsIGl0IGNhbiBzZW5kIAphbiBB Q0sgd2l0aCB0aGUgQ0xPQ0sgb3B0aW9uLiBPbmNlIHRoZSBjb21wcmVzc29yIGdldHMgdGhlIENM T0NLLW9wdCBmcm9tIAp0aGUgZGVjb21wcmVzc29yIGl0IGNhbiBjaGFuZ2UgdG8gdGhlIOKAnHRp bWVyLWJhc2Vk4oCdIGNvbXByZXNzaW9uLiBCdXQgaXQgCmRvZXNu4oCZdCBsZXQgdGhlIGRlY29t cHJlc3NvciBrbm93IHByZWNpc2VseSB3aGVuIHRvIHN0YXJ0IGV4cGVjdGluZyAKcGFja2V0cyBj b21wcmVzc2VkIHdpdGgg4oCcdGltZXItYmFzZWTigJ0gY29tcHJlc3Npb24uICBUaGVyZSBoYXMg dG8gYmUgc29tZSAKd2F5IHRvIHRlbGwgdGhlIGRlY29tcHJlc3NvciB0aGF0IHRoZSBjdXJyZW50 IHBhY2tldCBpcyBjb21wcmVzc2VkIHdpdGggCnRoZSDigJx0aW1lci1iYXNlZOKAnSBjb21wcmVz c2lvbiBhbGdvLiAgSSBkb27igJl0IHNlZSBhbnkgZmxhZ3MgZm9yIHRoaXMgaW4gdGhlIApSRkMu IE9uZSBoYXMgdG8gY29uc2lkZXIgdGhlIG51bWJlciBvZiBwYWNrZXRzIG9uIHRyYW5zaXQgYmVm b3JlIGRlY2lkaW5nIAp0byBjaGFuZ2UgdGhlIGNvbXByZXNzaW9uIGFsZ29yaXRobSBhZnRlciB0 aGUgaW5pdGlhbCBuZWdvdGlhdGlvbi4gCiAKVGhhbmtzCkJpcGxhYgogCgpGcm9tOiByb2hjLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2hjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiAKS2F2aXRoYSBLUgpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNSwgMjAwNiAxMjozNyBQTQpU bzogcm9oY0BpZXRmLm9yZwpTdWJqZWN0OiBSZTogW3JvaGNdIFRpbWVyLWJhc2VkIGNvbXByZXNz aW9uCiAKCkhpLCAKCkNvbXByZXNzb3IgY2FuIGJlIG1hZGUgdG8gc2VuZCBhbiBVT1ItMiBwYWNr ZXQgd2l0aCBleHQtMyBvciBJUi9JUi1EWU4gCnBhY2tldCB3aXRoIFRJUz0xIGFuZCBUSU1FX1NU UklERSB2YWx1ZSBiZWZvcmUgaXQgYmVnaW5zIHRvIGRvIFRpbWVyIGJhc2VkIApDb21wcmVzc2lv biBvZiBUUy4gIEl0IGlzIGEgd2F5IHRvIGluZGljYXRlIHRpbWVyLWJhc2VkIGNvbXByZXNzaW9u IG9mIFRTIAp0byB0aGUgZGVjb21wcmVzc29yLiAKKFJlZmVyIFJGQyAzMDk1IFNlYyA1LjcuNSAg RXh0ZW5zaW9uIEZvcm1hdHMpIAoKS2F2aXRoYSBLLlIuLApMJlQgSW5mb3RlY2gsCkJhbmdhbG9y ZS4KCiggKSBMJlQgSW5mb3RlY2ggUHJvcHJpZXRhcnkgJiBDb25maWRlbnRpYWwKKCApIEwmVCBJ bmZvdGVjaCBDb25maWRlbnRpYWwKKCkgTCZUIEluZm90ZWNoIEludGVybmFsIFVzZSBvbmx5Cigr KSBHZW5lcmFsIEJ1c2luZXNzIEluZm9ybWF0aW9uIAoKCiJTYXJrYXIsIEJpcGxhYiIgPGJzYXJr YXJAc3RhcmVudG5ldHdvcmtzLmNvbT4gClNlbnQgYnk6IHJvaGMtYm91bmNlc0BpZXRmLm9yZyAK MDEvMDUvMjAwNiAxMTo0MSBBTSAKCgpUbwo8cm9oY0BpZXRmLm9yZz4gCmNjCiAKU3ViamVjdApb cm9oY10gVGltZXItYmFzZWQgY29tcHJlc3Npb24KIAoKCiAKIAoKCgoKQWxsLCAKICAKSSBoYXZl IGEgcXVlcnkuIAogIApIb3cgZG9lcyB0aGUgZGVjb21wcmVzc29yIGtub3cg4oCcZnJvbeKAnSB3 aGljaCBwYWNrZXQgb253YXJkIGl0IHdvdWxkIGJlIApnZXR0aW5nIHBhY2tldHMgZW5jb2RlZCB3 aXRoIHRpbWVyLWJhc2VkLWNvbXByZXNzaW9uPyBTaW5jZSB0aGUgQUNLIGZyb20gCnRoZSBkZWNv bXByZXNzb3Igd2hpY2ggY2FycmllcyB0aGUgQ0xPQ0sgb3B0aW9uIG1pZ2h0IHRha2Ugc29tZSB0 aW1lIHRvIApyZWFjaCBhbmQgZ2V0IHByb2Nlc3NlZCBhdCB0aGUgY29tcHJlc3NvcjsgaXMgdGhl cmUgYW55IHdheSBmb3IgdGhlIApkZWNvbXByZXNzb3IgdG8ga25vdyB3aGVuIHRvIGV4cGVjdCBw YWNrZXRzIHRvIGJlIGVuY29kZWQgd2l0aCB0aGUgCnRpbWVyLWJhc2VkIGNvbXByZXNzaW9uIG1l dGhvZC4gCiAgClRoYW5rcyAKQmlwbGFiIAogIAorKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKyAKQmlwbGFiIFNhcmthciAKU3RhcmVudCBOZXR3b3JrcywgQmFuZ2Fsb3JlIAorKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKyAKIAoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpSb2hjIG1haWxpbmcgbGlzdApSb2hj QGlldGYub3JnCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvaGMKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KIlRoaXMgZW1haWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gb2YgClN0YXJlbnQgTmV0d29ya3MsIENvcnAuIFRoZSBp bmZvcm1hdGlvbiB0cmFuc21pdHRlZCBtYXkgbm90IGJlIHVzZWQgdG8gCmNyZWF0ZSBvciBjaGFu Z2UgYW55IGNvbnRyYWN0dWFsIG9ibGlnYXRpb25zIG9mIFN0YXJlbnQgTmV0d29ya3MsIENvcnAu IApBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciB1c2Ug b2YsIG9yIHRha2luZyBvZiAKYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uIHRoaXMgZS1tYWls IGFuZCBpdHMgYXR0YWNobWVudHMgYnkgcGVyc29ucyBvciAKZW50aXRpZXMgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IAp0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg LS0gYnkgCnJlcGx5aW5nIHRvIHRoaXMgbWVzc2FnZSBvciBieSBzZW5kaW5nIGFuIGVtYWlsIHRv IApwb3N0bWFzdGVyQHN0YXJlbnRuZXR3b3Jrcy5jb20gLS0gYW5kIGRlc3Ryb3kgYWxsIGNvcGll cyBvZiB0aGlzIG1lc3NhZ2UgCmFuZCBhbnkgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5nIG9y IGRpc2Nsb3NpbmcgdGhlaXIgY29udGVudHMuIFRoYW5rIAp5b3UuIiAKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18K --=_alternative 002C6E02652570ED_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGkgQmlwbGFiLDwvZm9udD4KPGJy Pgo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBleHBsYW5hdGlvbiBnaXZl biBmb3IgVElNRV9TVFJJREUKZmllbGQgaW4gJnF1b3Q7U2VjIDUuNy41LUV4dGVuc2lvbiBGb3Jt YXRzLVJUUCBoZWFkZXIgZmxhZ3MgYW5kIGZpZWxkcyZxdW90OwppcyB0aGlzOjwvZm9udD4KPGJy Pgo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRJTUVfU1RSSURFOiA8L2ZvbnQ+ Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UHJlZGljdGVkIHRpbWUgaW50ZXJ2 YWwgaW4gbWlsbGlzZWNvbmRzCmJldHdlZW48L2ZvbnQ+Cjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Y2hhbmdlcyBpbiB0aGUgUlRQIFRpbWVzdGFtcC4gQWxzbyBhbgppbmRpY2F0 aW9uIHRoYXQgdGhlPC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNv bXByZXNzb3IgZGVzaXJlcyB0byBwZXJmb3JtIHRpbWVyLWJhc2VkCmNvbXByZXNzaW9uIG9mIHRo ZSBSVFA8L2ZvbnQ+Cjxicj4KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JdCBz ZWVtcyBzZW5kaW5nIG9mIFRJTUVfU1RSSURFIGZpZWxkCmJ5IHRoZSBjb21wcmVzc29yIG1lYW5z IHRoYXQgaXQgJnF1b3Q7YWN0dWFsbHkmcXVvdDsgd2FudHMgdG8gcGVyZm9ybSBUaW1lcgpCYXNl ZCBDb21wcmVzc2lvbiBhbmQgbm90IGEgPC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPm1lcmUgJnF1b3Q7Y2FwYWJpbGl0eSBpbmRpY2F0aW9uJnF1b3Q7LjwvZm9udD4K PGJyPgo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJSLDwvZm9udD4KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5LYXZpdGhhIEsuUi4sPGJyPgpMJmFtcDtUIElu Zm90ZWNoLDxicj4KQmFuZ2Fsb3JlLjxicj4KPGJyPgooICkgTCZhbXA7VCBJbmZvdGVjaCBQcm9w cmlldGFyeSAmYW1wOyBDb25maWRlbnRpYWw8YnI+CiggKSBMJmFtcDtUIEluZm90ZWNoIENvbmZp ZGVudGlhbDxicj4KKCkgTCZhbXA7VCBJbmZvdGVjaCBJbnRlcm5hbCBVc2Ugb25seTxicj4KKCsg KSBHZW5lcmFsIEJ1c2luZXNzIEluZm9ybWF0aW9uPC9mb250Pgo8YnI+Cjxicj4KPGJyPgo8YnI+ Cjx0YWJsZSB3aWR0aD0xMDAlPgo8dHIgdmFsaWduPXRvcD4KPHRkIHdpZHRoPTQwJT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7U2Fya2FyLCBCaXBsYWImcXVvdDsKJmx0 O2JzYXJrYXJAc3RhcmVudG5ldHdvcmtzLmNvbSZndDs8L2I+IDwvZm9udD4KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAxLzA1LzIwMDYgMTI6NTUgUE08L2ZvbnQ+Cjx0ZCB3aWR0 aD01OSU+Cjx0YWJsZSB3aWR0aD0xMDAlPgo8dHIgdmFsaWduPXRvcD4KPHRkPgo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtLYXZpdGhhIEtSJnF1b3Q7ICZs dDtLYXZpdGhhLktSQGxudGluZm90ZWNoLmNvbSZndDs8L2ZvbnQ+Cjx0ciB2YWxpZ249dG9wPgo8 dGQ+CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9m b250PjwvZGl2Pgo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtyb2hjQGll dGYub3JnJmd0OzwvZm9udD4KPHRyIHZhbGlnbj10b3A+Cjx0ZD4KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW3JvaGNdIFRpbWVyLWJhc2VkIGNvbXBy ZXNzaW9uPC9mb250PjwvdGFibGU+Cjxicj4KPHRhYmxlPgo8dHIgdmFsaWduPXRvcD4KPHRkPgo8 dGQ+PC90YWJsZT4KPGJyPjwvdGFibGU+Cjxicj4KPGJyPgo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBNUyI+SGkgS2F2aXRoYSw8L2ZvbnQ+Cjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj4mbmJzcDs8L2ZvbnQ+ Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj5JIGJl bGlldmUgd2l0aCB0aGUKVU9SLTIrZXh0LTMgdGhlIGNvbXByZXNzb3Igc2F5cyB0aGF0IGl0IOKA nGNhbuKAnSBzdXBwb3J0IOKAnHRpbWVyLWJhc2Vk4oCdCmNvbXByZXNzaW9uLiBJZiB0aGUgZGVj b21wcmVzc29yIHN1cHBvcnRzIHRoaXMsIGl0IGNhbiBzZW5kIGFuIEFDSyB3aXRoCnRoZSBDTE9D SyBvcHRpb24uIE9uY2UgdGhlIGNvbXByZXNzb3IgZ2V0cyB0aGUgQ0xPQ0stb3B0IGZyb20gdGhl IGRlY29tcHJlc3NvcgppdCBjYW4gY2hhbmdlIHRvIHRoZSDigJx0aW1lci1iYXNlZOKAnSBjb21w cmVzc2lvbi4gQnV0IGl0IGRvZXNu4oCZdCBsZXQgdGhlCmRlY29tcHJlc3NvciBrbm93IHByZWNp c2VseSB3aGVuIHRvIHN0YXJ0IGV4cGVjdGluZyBwYWNrZXRzIGNvbXByZXNzZWQKd2l0aCDigJx0 aW1lci1iYXNlZOKAnSBjb21wcmVzc2lvbi4gJm5ic3A7VGhlcmUgaGFzIHRvIGJlIHNvbWUgd2F5 IHRvIHRlbGwKdGhlIGRlY29tcHJlc3NvciB0aGF0IHRoZSBjdXJyZW50IHBhY2tldCBpcyBjb21w cmVzc2VkIHdpdGggdGhlIOKAnHRpbWVyLWJhc2Vk4oCdCmNvbXByZXNzaW9uIGFsZ28uICZuYnNw O0kgZG9u4oCZdCBzZWUgYW55IGZsYWdzIGZvciB0aGlzIGluIHRoZSBSRkMuIE9uZQpoYXMgdG8g Y29uc2lkZXIgdGhlIG51bWJlciBvZiBwYWNrZXRzIG9uIHRyYW5zaXQgYmVmb3JlIGRlY2lkaW5n IHRvIGNoYW5nZQp0aGUgY29tcHJlc3Npb24gYWxnb3JpdGhtIGFmdGVyIHRoZSBpbml0aWFsIG5l Z290aWF0aW9uLiA8L2ZvbnQ+Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJD b21pYyBTYW5zIE1TIj4mbmJzcDs8L2ZvbnQ+Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4 MCBmYWNlPSJDb21pYyBTYW5zIE1TIj5UaGFua3M8L2ZvbnQ+Cjxicj48Zm9udCBzaXplPTIgY29s b3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj5CaXBsYWI8L2ZvbnQ+Cjxicj48Zm9udCBz aXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj4mbmJzcDs8L2ZvbnQ+Cjxk aXYgYWxpZ249Y2VudGVyPgo8YnI+Cjxocj48L2Rpdj4KPGJyPjxmb250IHNpemU9MiBmYWNlPSJU YWhvbWEiPjxiPkZyb206PC9iPiByb2hjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2hjLWJv dW5jZXNAaWV0Zi5vcmddCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2F2aXRoYSBLUjxiPjxicj4KU2Vu dDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAyMDA2IDEyOjM3IFBNPGI+PGJyPgpUbzo8L2I+ IHJvaGNAaWV0Zi5vcmc8Yj48YnI+ClN1YmplY3Q6PC9iPiBSZTogW3JvaGNdIFRpbWVyLWJhc2Vk IGNvbXByZXNzaW9uPC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4K SGksPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+CjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPgpDb21wcmVzc29yIGNhbiBiZSBt YWRlIHRvIHNlbmQgYW4gVU9SLTIgcGFja2V0IHdpdGggZXh0LTMgb3IgSVIvSVItRFlOCnBhY2tl dCB3aXRoIFRJUz0xIGFuZCBUSU1FX1NUUklERSB2YWx1ZSBiZWZvcmUgaXQgYmVnaW5zIHRvIGRv IFRpbWVyIGJhc2VkCkNvbXByZXNzaW9uIG9mIFRTLiAmbmJzcDtJdCBpcyBhIHdheSB0byBpbmRp Y2F0ZSB0aW1lci1iYXNlZCBjb21wcmVzc2lvbgpvZiBUUyB0byB0aGUgZGVjb21wcmVzc29yLiA8 YnI+CihSZWZlciBSRkMgMzA5NSBTZWMgNS43LjUgJm5ic3A7RXh0ZW5zaW9uIEZvcm1hdHMpPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgo8YnI+CjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPgpLYXZpdGhhIEsuUi4sPGJyPgpMJmFtcDtU IEluZm90ZWNoLDxicj4KQmFuZ2Fsb3JlLjxicj4KPGJyPgooICkgTCZhbXA7VCBJbmZvdGVjaCBQ cm9wcmlldGFyeSAmYW1wOyBDb25maWRlbnRpYWw8YnI+CiggKSBMJmFtcDtUIEluZm90ZWNoIENv bmZpZGVudGlhbDxicj4KKCkgTCZhbXA7VCBJbmZvdGVjaCBJbnRlcm5hbCBVc2Ugb25seTxicj4K KCspIEdlbmVyYWwgQnVzaW5lc3MgSW5mb3JtYXRpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Cjxicj4KPC9mb250Pgo8cD4KPHRhYmxlIHdpZHRoPTEwMCU+Cjx0 ciB2YWxpZ249dG9wPgo8dGQgd2lkdGg9NjAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj4mcXVvdDtTYXJrYXIsIEJpcGxhYiZxdW90OwombHQ7YnNhcmthckBzdGFyZW50bmV0d29y a3MuY29tJmd0OzwvYj4gPGJyPgpTZW50IGJ5OiByb2hjLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+CjwvZm9udD4KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAxLzA1LzIwMDYgMTE6NDEgQU08L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+CjwvZm9udD4KPHRkIHdpZHRoPTM5JT4KPGJyPgo8 dGFibGUgd2lkdGg9MTAwJT4KPHRyIHZhbGlnbj10b3A+Cjx0ZCB3aWR0aD0xOSU+CjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pgo8 dGQgd2lkdGg9ODAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7cm9oY0BpZXRm Lm9yZyZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+CjwvZm9u dD4KPHRyIHZhbGlnbj10b3A+Cjx0ZD4KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+Cjx0ZD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+Cjx0ciB2YWxpZ249dG9wPgo8dGQ+CjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9k aXY+Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3JvaGNdIFRpbWVyLWJhc2Vk IGNvbXByZXNzaW9uPC9mb250PjwvdGFibGU+Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+CjxwPgo8YnI+Cjx0YWJsZSB3aWR0aD0xMDAlPgo8dHIg dmFsaWduPXRvcD4KPHRkIHdpZHRoPTUwJT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4mbmJzcDs8L2ZvbnQ+Cjx0ZCB3aWR0aD01MCU+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvdGFibGU+Cjxicj48L3RhYmxlPgo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPgo8YnI+CjwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj48YnI+CkFsbCw8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj48YnI+CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxicj4KSSBoYXZlIGEgcXVlcnkuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBNUyI+PGJyPgogPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj48YnI+CkhvdyBkb2VzIHRoZSBkZWNvbXByZXNz b3Iga25vdyDigJxmcm9t4oCdIHdoaWNoIHBhY2tldCBvbndhcmQgaXQgd291bGQgYmUKZ2V0dGlu ZyBwYWNrZXRzIGVuY29kZWQgd2l0aCB0aW1lci1iYXNlZC1jb21wcmVzc2lvbj8gU2luY2UgdGhl IEFDSyBmcm9tCnRoZSBkZWNvbXByZXNzb3Igd2hpY2ggY2FycmllcyB0aGUgQ0xPQ0sgb3B0aW9u IG1pZ2h0IHRha2Ugc29tZSB0aW1lIHRvCnJlYWNoIGFuZCBnZXQgcHJvY2Vzc2VkIGF0IHRoZSBj b21wcmVzc29yOyBpcyB0aGVyZSBhbnkgd2F5IGZvciB0aGUgZGVjb21wcmVzc29yCnRvIGtub3cg d2hlbiB0byBleHBlY3QgcGFja2V0cyB0byBiZSBlbmNvZGVkIHdpdGggdGhlIHRpbWVyLWJhc2Vk IGNvbXByZXNzaW9uCm1ldGhvZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5z IE1TIj48YnI+CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i c3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxicj4KVGhhbmtzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBNUyI+PGJy PgpCaXBsYWI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj48YnI+CiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjxm b250IHNpemU9MSBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxiPjxicj4KKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKys8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPgo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSMwMDAwODAgZmFj ZT0iQ29taWMgU2FucyBNUyI+PGI+PGJyPgpCaXBsYWIgU2Fya2FyPC9iPjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0j MDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxiPjxicj4KU3RhcmVudCBOZXR3b3JrcywgQmFu Z2Fsb3JlPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KPC9m b250Pjxmb250IHNpemU9MSBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjxiPjxi cj4KKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKys8L2I+PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgo8YnI+CiAmbmJzcDs8L2ZvbnQ+CjxwPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPgpSb2hjIG1haWxpbmcgbGlzdDxicj4KUm9oY0BpZXRmLm9y Zzxicj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9oYzwvZm9udD4K PHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PC9mb250Pgo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mcXVvdDtUaGlz IGVtYWlsIG1lc3NhZ2UgYW5kIGFueQphdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIG9mIFN0YXJlbnQgTmV0d29ya3MsIENvcnAuIFRoZQppbmZvcm1hdGlvbiB0cmFuc21p dHRlZCBtYXkgbm90IGJlIHVzZWQgdG8gY3JlYXRlIG9yIGNoYW5nZSBhbnkgY29udHJhY3R1YWwK b2JsaWdhdGlvbnMgb2YgU3RhcmVudCBOZXR3b3JrcywgQ29ycC4gQW55IHJldmlldywgcmV0cmFu c21pc3Npb24sIGRpc3NlbWluYXRpb24Kb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55 IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uIHRoaXMgZS1tYWlsIGFuZAppdHMgYXR0YWNobWVudHMg YnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQK aXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUKc2VuZGVyIGltbWVkaWF0ZWx5IC0tIGJ5IHJlcGx5aW5nIHRvIHRoaXMg bWVzc2FnZSBvciBieSBzZW5kaW5nIGFuIGVtYWlsCnRvIHBvc3RtYXN0ZXJAc3RhcmVudG5ldHdv cmtzLmNvbSAtLSBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZQphbmQgYW55 IGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGluZyBvciBkaXNjbG9zaW5nIHRoZWlyIGNvbnRlbnRz LiBUaGFuawp5b3UuJnF1b3Q7IDxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD4KPHA+Cgo8QlI+Cl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+Cgo= --=_alternative 002C6E02652570ED_=-- --===============0932516239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0932516239==-- From rohc-bounces@ietf.org Thu Jan 05 03:31:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQX6-0001YA-GM; Thu, 05 Jan 2006 03:31:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQX4-0001WB-Hc for rohc@megatron.ietf.org; Thu, 05 Jan 2006 03:31:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10896 for ; Thu, 5 Jan 2006 03:30:22 -0500 (EST) Received: from mail43.messagelabs.com ([216.82.255.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuQci-0000RE-Bm for rohc@ietf.org; Thu, 05 Jan 2006 03:37:29 -0500 X-VirusChecked: Checked X-Env-Sender: Kavitha.KR@lntinfotech.com X-Msg-Ref: server-5.tower-43.messagelabs.com!1136449883!29163105!2 X-StarScan-Version: 5.5.9.1; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 25575 invoked from network); 5 Jan 2006 08:31:25 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-5.tower-43.messagelabs.com with SMTP; 5 Jan 2006 08:31:25 -0000 Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006010514012356-12267 ; Thu, 5 Jan 2006 14:01:23 +0530 To: rohc@ietf.org Subject: RE: [rohc] Timer-based compression MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Kavitha KR Date: Thu, 5 Jan 2006 14:05:18 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:05:18 PM, Serialize complete at 01/05/2006 02:05:18 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:01:23 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:01:25 PM, Serialize complete at 01/05/2006 02:01:25 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0728766791==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multipart message in MIME format. --===============0728766791== Content-Type: multipart/alternative; boundary="=_alternative 002ED70C652570ED_=" This is a multipart message in MIME format. --=_alternative 002ED70C652570ED_= Content-Type: text/plain; charset="US-ASCII" Hi, There could be 4 cases for switching from scaled TS compression to Timer based compression of RTP TS. Scenario 1 : Decompressor initializes and compressor accepts ===================================================== Packet flow with scaled timestamp compression going on................. D => send feedback with CLOCK option C => send TIME_STRIDE information (timer based compression starts here) Further packet flow continues with timer based compression.................. Scenario 2: Compressor initializes and decompressor accepts ===================================================== Packet flow with scaled timestamp compression going on................. C=> send TIME_STRIDE information (timer based compression starts here) D=> send feedback with CLOCK option Further packet flow continues with timer based compression.................. Scenario 3: Decompressor initializes and compressor rejects ===================================================== Packet flow with scaled timestamp compression going on................. D => send feedback with CLOCK option C=> No TIME_STRIDE info is sent (indicates not wanting to switch to Timer Based) Further packet flow continues with scaled timestamp compression.................. Scenario 4: Compressor initializes and decompressor rejects ===================================================== Packet flow with scaled timestamp compression going on................. C =>send TIME_STRIDE information D=> send feedback with CLOCK option set to zero (means no desire to do timer based compression) Further packet flow continues with scaled timestamp compression.................. For various compressor and decompressor implementations to interoperate, this may be the minimum set to be taken care. ================================================= When your work speaks for itself, get out of the way. -- Thomas 'Wayne' Brazell ================================================= Kavitha K.R., L&T Infotech, Bangalore. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information "Kristofer Sandlund \(LU/EAB\)" 01/05/2006 01:26 PM To "Sarkar, Biplab" , "Kavitha KR" cc Subject RE: [rohc] Timer-based compression Hi, Implementer's guide section 4.3: Before timer-based compression can be used, the decompressor will have to inform the compressor (on a per-channel basis) about its clock resolution. Further, the compressor has to send (on a per- context basis) a non-zero TIME_STRIDE to the decompressor. When the compressor is confident that the decompressor has received the TIME_STRIDE value, it can switch to timer-based compression. During this transition from window-based compression to timer-based compression, it is necessary that the compressor keep k large enough to cover both interpretation intervals. So the procedure is: 0) TIME_STRIDE starts out as zero 1) CLOCK option is sent by decompressor and received by compressor 2) Compressor decides that it wants to use timer-based compression. If so, the compressor sends a non-zero TIME_STRIDE 3) Compressor repeats time-stride until it is _confident_ that the decompressor has correctly received the new TIME_STRIDE. Note that these packet are already encoded with timer-based compression since they contain a time-stride that is non-zero. 4) All packets sent after this that contain an encoded timestamp are assumed to be using timer-based compression. The timer-based compression initialization seems to be the most frequent question on this list, but I don't know how to improve the text in the impl-guide any further. I thought it was quite clear now, but obviously it still isn't good enough. Do you have any suggestions on how to improve it further? BR, Kristofer rohc-bounces@ietf.org wrote: > Hi Kavitha, > > > > I believe with the UOR-2+ext-3 the compressor says that it > "can" support "timer-based" compression. If the decompressor > supports this, it can send an ACK with the CLOCK option. Once > the compressor gets the CLOCK-opt from the decompressor it > can change to the "timer-based" compression. But it doesn't > let the decompressor know precisely when to start expecting > packets compressed with "timer-based" compression. There has > to be some way to tell the decompressor that the current > packet is compressed with the "timer-based" compression algo. > I don't see any flags for this in the RFC. One has to > consider the number of packets on transit before deciding to > change the compression algorithm after the initial negotiation. > > > > Thanks > > Biplab > > > > ________________________________ > > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf > Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM > To: rohc@ietf.org > Subject: Re: [rohc] Timer-based compression > > > > > Hi, > > Compressor can be made to send an UOR-2 packet with ext-3 or > IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it > begins to do Timer based Compression of TS. It is a way to > indicate timer-based compression of TS to the decompressor. > (Refer RFC 3095 Sec 5.7.5 Extension Formats) > > Kavitha K.R., > L&T Infotech, > Bangalore. > > ( ) L&T Infotech Proprietary & Confidential > ( ) L&T Infotech Confidential > () L&T Infotech Internal Use only > (+) General Business Information > > > > "Sarkar, Biplab" > Sent by: rohc-bounces@ietf.org > > 01/05/2006 11:41 AM > > To > > > > cc > > > > Subject > > [rohc] Timer-based compression > > > > > > > > > > > All, > > I have a query. > > How does the decompressor know "from" which packet onward it > would be getting packets encoded with > timer-based-compression? Since the ACK from the decompressor > which carries the CLOCK option might take some time to reach > and get processed at the compressor; is there any way for the > decompressor to know when to expect packets to be encoded > with the timer-based compression method. > > Thanks > Biplab > > ++++++++++++++++++++++++++++++++ > Biplab Sarkar > Starent Networks, Bangalore > ++++++++++++++++++++++++++++++++ > > > > ______________________________________________________________ > _______________________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > > > ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ --=_alternative 002ED70C652570ED_= Content-Type: text/html; charset="US-ASCII"
Hi,

There could be 4 cases for switching from scaled TS compression to Timer based compression of RTP TS.

Scenario 1 : Decompressor initializes and compressor accepts
=====================================================
Packet flow with scaled timestamp compression going on.................
D => send feedback with CLOCK option
C => send TIME_STRIDE information (timer based compression starts here)
Further packet flow continues with timer based compression..................

Scenario 2: Compressor initializes and decompressor accepts
=====================================================
Packet flow with scaled timestamp compression going on.................
C=> send TIME_STRIDE information (timer based compression starts here)
D=> send feedback with CLOCK option
Further packet flow continues with timer based compression..................

Scenario 3: Decompressor initializes and compressor rejects
=====================================================
Packet flow with scaled timestamp compression going on.................
D => send feedback with CLOCK option
C=> No TIME_STRIDE info is sent (indicates not wanting to switch to Timer Based)
Further packet flow continues with scaled timestamp compression..................

Scenario 4: Compressor initializes and decompressor rejects
=====================================================
Packet flow with scaled timestamp compression going on.................
C =>send TIME_STRIDE information
D=> send feedback with CLOCK option set to zero (means no desire to do timer based compression)
Further packet flow continues with scaled timestamp compression..................

For various compressor and decompressor implementations to interoperate, this may be the minimum set to be taken care.


=================================================
When your work speaks for itself, get out of the way.
-- Thomas 'Wayne' Brazell
=================================================
Kavitha K.R.,
L&T Infotech,
Bangalore.

( ) L&T Infotech Proprietary & Confidential
( ) L&T Infotech Confidential
(+) L&T Infotech Internal Use only
( ) General Business Information


"Kristofer Sandlund \(LU/EAB\)" <kristofer.sandlund@ericsson.com>

01/05/2006 01:26 PM

To
"Sarkar, Biplab" <bsarkar@starentnetworks.com>, "Kavitha KR" <Kavitha.KR@lntinfotech.com>
cc
<rohc@ietf.org>
Subject
RE: [rohc] Timer-based compression





Hi,

Implementer's guide section 4.3:

  Before timer-based compression can be used, the decompressor will
  have to inform the compressor (on a per-channel basis) about its
  clock resolution. Further, the compressor has to send (on a per-
  context basis) a non-zero TIME_STRIDE to the decompressor.

  When the compressor is confident that the decompressor has received
  the TIME_STRIDE value, it can switch to timer-based compression.
  During this transition from window-based compression to timer-based
  compression, it is necessary that the compressor keep k large enough
  to cover both interpretation intervals.

So the procedure is:
0) TIME_STRIDE starts out as zero
1) CLOCK option is sent by decompressor and received by compressor
2) Compressor decides that it wants to use timer-based compression.
  If so, the compressor sends a non-zero TIME_STRIDE
3) Compressor repeats time-stride until it is _confident_ that the
  decompressor has correctly received the new TIME_STRIDE. Note that
  these packet are already encoded with timer-based compression since
  they contain a time-stride that is non-zero.
4) All packets sent after this that contain an encoded timestamp are
  assumed to be using timer-based compression.

The timer-based compression initialization seems to be the most frequent
question on this list, but I don't know how to improve the text in the
impl-guide any further. I thought it was quite clear now, but obviously
it still isn't good enough. Do you have any suggestions on how to
improve it further?

BR,
                Kristofer


rohc-bounces@ietf.org <mailto:rohc-bounces@ietf.org> wrote:

> Hi Kavitha,
>
>
>
> I believe with the UOR-2+ext-3 the compressor says that it
> "can" support "timer-based" compression. If the decompressor
> supports this, it can send an ACK with the CLOCK option. Once
> the compressor gets the CLOCK-opt from the decompressor it
> can change to the "timer-based" compression. But it doesn't
> let the decompressor know precisely when to start expecting
> packets compressed with "timer-based" compression.  There has
> to be some way to tell the decompressor that the current
> packet is compressed with the "timer-based" compression algo.
>  I don't see any flags for this in the RFC. One has to
> consider the number of packets on transit before deciding to
> change the compression algorithm after the initial negotiation.
>
>
>
> Thanks
>
> Biplab
>
>
>
> ________________________________
>
> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf
> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM
> To: rohc@ietf.org
> Subject: Re: [rohc] Timer-based compression
>
>
>
>
> Hi,
>
> Compressor can be made to send an UOR-2 packet with ext-3 or
> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it
> begins to do Timer based Compression of TS.  It is a way to
> indicate timer-based compression of TS to the decompressor.
> (Refer RFC 3095 Sec 5.7.5  Extension Formats)
>
> Kavitha K.R.,
> L&T Infotech,
> Bangalore.
>
> ( ) L&T Infotech Proprietary & Confidential
> ( ) L&T Infotech Confidential
> () L&T Infotech Internal Use only
> (+) General Business Information
>
>
>
> "Sarkar, Biplab" <bsarkar@starentnetworks.com>
> Sent by: rohc-bounces@ietf.org
>
> 01/05/2006 11:41 AM
>
> To
>
> <rohc@ietf.org>
>
> cc
>
>
>
> Subject
>
> [rohc] Timer-based compression
>
>
>
>
>
>
>
>
>
>
> All,
>
> I have a query.
>
> How does the decompressor know "from" which packet onward it
> would be getting packets encoded with
> timer-based-compression? Since the ACK from the decompressor
> which carries the CLOCK option might take some time to reach
> and get processed at the compressor; is there any way for the
> decompressor to know when to expect packets to be encoded
> with the timer-based compression method.
>
> Thanks
> Biplab
>
> ++++++++++++++++++++++++++++++++
> Biplab Sarkar
> Starent Networks, Bangalore
> ++++++++++++++++++++++++++++++++
>
>
>
> ______________________________________________________________
> _______________________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>
>
> ______________________________________________________________________


______________________________________________________________________

______________________________________________________________________
--=_alternative 002ED70C652570ED_=-- --===============0728766791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0728766791==-- From rohc-bounces@ietf.org Thu Jan 05 03:40:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQfm-0005Zh-T5; Thu, 05 Jan 2006 03:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQfk-0005Zc-PV for rohc@megatron.ietf.org; Thu, 05 Jan 2006 03:40:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11820 for ; Thu, 5 Jan 2006 03:39:20 -0500 (EST) Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuQlM-0000gK-Io for rohc@ietf.org; Thu, 05 Jan 2006 03:46:27 -0500 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id EA41737E96; Thu, 5 Jan 2006 09:40:16 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id D25D137E8F; Thu, 5 Jan 2006 09:40:16 +0100 (CET) Received: from jymden (81-235-131-199-no14.tbcn.telia.com [81.235.131.199]) by smtp4-1-sn2.hy.skanova.net (Postfix) with SMTP id D9BC737E42; Thu, 5 Jan 2006 09:40:10 +0100 (CET) Message-ID: <002d01c611d3$bd400960$6500a8c0@jymden> From: "Lars-Erik Jonsson" To: , "Kavitha KR" References: Subject: Re: [rohc] Timer-based compression Date: Thu, 5 Jan 2006 09:40:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Kavitha, As said in the implementer's guide, "Before timer-based compression can be used, the decompressor will have to inform the compressor (on a per- channel basis) about its clock resolution." This means only scenario 1 and 3 make sense. The compressor is not allowed to start timer-based compression before the decompressor has sent the clock resolution (i.e. the CLOCK option). BR /L-E ----- Original Message ----- From: "Kavitha KR" To: Sent: Thursday, January 05, 2006 9:35 AM Subject: RE: [rohc] Timer-based compression > Hi, > > There could be 4 cases for switching from scaled TS compression to Timer > based compression of RTP TS. > > Scenario 1 : Decompressor initializes and compressor accepts > ===================================================== > Packet flow with scaled timestamp compression going on................. > D => send feedback with CLOCK option > C => send TIME_STRIDE information (timer based compression starts here) > Further packet flow continues with timer based > compression.................. > > Scenario 2: Compressor initializes and decompressor accepts > ===================================================== > Packet flow with scaled timestamp compression going on................. > C=> send TIME_STRIDE information (timer based compression starts here) > D=> send feedback with CLOCK option > Further packet flow continues with timer based > compression.................. > > Scenario 3: Decompressor initializes and compressor rejects > ===================================================== > Packet flow with scaled timestamp compression going on................. > D => send feedback with CLOCK option > C=> No TIME_STRIDE info is sent (indicates not wanting to switch to Timer > Based) > Further packet flow continues with scaled timestamp > compression.................. > > Scenario 4: Compressor initializes and decompressor rejects > ===================================================== > Packet flow with scaled timestamp compression going on................. > C =>send TIME_STRIDE information > D=> send feedback with CLOCK option set to zero (means no desire to do > timer based compression) > Further packet flow continues with scaled timestamp > compression.................. > > For various compressor and decompressor implementations to interoperate, > this may be the minimum set to be taken care. > > > ================================================= > When your work speaks for itself, get out of the way. > -- Thomas 'Wayne' Brazell > ================================================= > Kavitha K.R., > L&T Infotech, > Bangalore. > > ( ) L&T Infotech Proprietary & Confidential > ( ) L&T Infotech Confidential > (+) L&T Infotech Internal Use only > ( ) General Business Information > > > > "Kristofer Sandlund \(LU/EAB\)" > 01/05/2006 01:26 PM > > To > "Sarkar, Biplab" , "Kavitha KR" > > cc > > Subject > RE: [rohc] Timer-based compression > > > > > > > Hi, > > Implementer's guide section 4.3: > > Before timer-based compression can be used, the decompressor will > have to inform the compressor (on a per-channel basis) about its > clock resolution. Further, the compressor has to send (on a per- > context basis) a non-zero TIME_STRIDE to the decompressor. > > When the compressor is confident that the decompressor has received > the TIME_STRIDE value, it can switch to timer-based compression. > During this transition from window-based compression to timer-based > compression, it is necessary that the compressor keep k large enough > to cover both interpretation intervals. > > So the procedure is: > 0) TIME_STRIDE starts out as zero > 1) CLOCK option is sent by decompressor and received by compressor > 2) Compressor decides that it wants to use timer-based compression. > If so, the compressor sends a non-zero TIME_STRIDE > 3) Compressor repeats time-stride until it is _confident_ that the > decompressor has correctly received the new TIME_STRIDE. Note that > these packet are already encoded with timer-based compression since > they contain a time-stride that is non-zero. > 4) All packets sent after this that contain an encoded timestamp are > assumed to be using timer-based compression. > > The timer-based compression initialization seems to be the most frequent > question on this list, but I don't know how to improve the text in the > impl-guide any further. I thought it was quite clear now, but obviously > it still isn't good enough. Do you have any suggestions on how to > improve it further? > > BR, > Kristofer > > > rohc-bounces@ietf.org wrote: > >> Hi Kavitha, >> >> >> >> I believe with the UOR-2+ext-3 the compressor says that it >> "can" support "timer-based" compression. If the decompressor >> supports this, it can send an ACK with the CLOCK option. Once >> the compressor gets the CLOCK-opt from the decompressor it >> can change to the "timer-based" compression. But it doesn't >> let the decompressor know precisely when to start expecting >> packets compressed with "timer-based" compression. There has >> to be some way to tell the decompressor that the current >> packet is compressed with the "timer-based" compression algo. >> I don't see any flags for this in the RFC. One has to >> consider the number of packets on transit before deciding to >> change the compression algorithm after the initial negotiation. >> >> >> >> Thanks >> >> Biplab >> >> >> >> ________________________________ >> >> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf >> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM >> To: rohc@ietf.org >> Subject: Re: [rohc] Timer-based compression >> >> >> >> >> Hi, >> >> Compressor can be made to send an UOR-2 packet with ext-3 or >> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it >> begins to do Timer based Compression of TS. It is a way to >> indicate timer-based compression of TS to the decompressor. >> (Refer RFC 3095 Sec 5.7.5 Extension Formats) >> >> Kavitha K.R., >> L&T Infotech, >> Bangalore. >> >> ( ) L&T Infotech Proprietary & Confidential >> ( ) L&T Infotech Confidential >> () L&T Infotech Internal Use only >> (+) General Business Information >> >> >> >> "Sarkar, Biplab" >> Sent by: rohc-bounces@ietf.org >> >> 01/05/2006 11:41 AM >> >> To >> >> >> >> cc >> >> >> >> Subject >> >> [rohc] Timer-based compression >> >> >> >> >> >> >> >> >> >> >> All, >> >> I have a query. >> >> How does the decompressor know "from" which packet onward it >> would be getting packets encoded with >> timer-based-compression? Since the ACK from the decompressor >> which carries the CLOCK option might take some time to reach >> and get processed at the compressor; is there any way for the >> decompressor to know when to expect packets to be encoded >> with the timer-based compression method. >> >> Thanks >> Biplab >> >> ++++++++++++++++++++++++++++++++ >> Biplab Sarkar >> Starent Networks, Bangalore >> ++++++++++++++++++++++++++++++++ >> >> >> >> ______________________________________________________________ >> _______________________________________________________ >> Rohc mailing list >> Rohc@ietf.org >> https://www1.ietf.org/mailman/listinfo/rohc >> >> >> ______________________________________________________________________ > > > ______________________________________________________________________ > > > > ______________________________________________________________________ -------------------------------------------------------------------------------- > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 05 03:49:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQoD-0008Nr-Ux; Thu, 05 Jan 2006 03:49:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQoC-0008Nj-3H for rohc@megatron.ietf.org; Thu, 05 Jan 2006 03:49:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12888 for ; Thu, 5 Jan 2006 03:48:03 -0500 (EST) Received: from mail47.messagelabs.com ([216.82.240.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuQtp-0000vg-TQ for rohc@ietf.org; Thu, 05 Jan 2006 03:55:10 -0500 X-VirusChecked: Checked X-Env-Sender: Kavitha.KR@lntinfotech.com X-Msg-Ref: server-4.tower-47.messagelabs.com!1136450944!30626713!2 X-StarScan-Version: 5.5.9.1; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 21730 invoked from network); 5 Jan 2006 08:49:06 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-4.tower-47.messagelabs.com with SMTP; 5 Jan 2006 08:49:06 -0000 Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006010514190338-12388 ; Thu, 5 Jan 2006 14:19:03 +0530 In-Reply-To: <002d01c611d3$bd400960$6500a8c0@jymden> To: rohc@ietf.org Subject: Re: [rohc] Timer-based compression MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Kavitha KR Date: Thu, 5 Jan 2006 14:22:57 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:22:58 PM, Serialize complete at 01/05/2006 02:22:58 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:19:03 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:19:06 PM, Serialize complete at 01/05/2006 02:19:06 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: d3308915082aec5bdcb405956a0eb0ae X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0296360585==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multipart message in MIME format. --===============0296360585== Content-Type: multipart/alternative; boundary="=_alternative 003074A1652570ED_=" This is a multipart message in MIME format. --=_alternative 003074A1652570ED_= Content-Type: text/plain; charset="US-ASCII" Hi L-E/Kristofer, But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 of 3095, "The smallest clock resolution which can be indicated is 1 millisecond. The value zero has a special meaning: it indicates that the decompressor cannot do timer-based compression of the RTP Timestamp." So even if there are impertinent Compressors (Scenario 2 and 4), Decompressors can still send CLOCK value zero and choose not to do timer based decompression. Isn't it so ? Regards, Kavitha K.R., L&T Infotech, Bangalore. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information "Lars-Erik Jonsson" 01/05/2006 02:10 PM To , "Kavitha KR" cc Subject Re: [rohc] Timer-based compression Kavitha, As said in the implementer's guide, "Before timer-based compression can be used, the decompressor will have to inform the compressor (on a per- channel basis) about its clock resolution." This means only scenario 1 and 3 make sense. The compressor is not allowed to start timer-based compression before the decompressor has sent the clock resolution (i.e. the CLOCK option). BR /L-E ----- Original Message ----- From: "Kavitha KR" To: Sent: Thursday, January 05, 2006 9:35 AM Subject: RE: [rohc] Timer-based compression > Hi, > > There could be 4 cases for switching from scaled TS compression to Timer > based compression of RTP TS. > > Scenario 1 : Decompressor initializes and compressor accepts > ===================================================== > Packet flow with scaled timestamp compression going on................. > D => send feedback with CLOCK option > C => send TIME_STRIDE information (timer based compression starts here) > Further packet flow continues with timer based > compression.................. > > Scenario 2: Compressor initializes and decompressor accepts > ===================================================== > Packet flow with scaled timestamp compression going on................. > C=> send TIME_STRIDE information (timer based compression starts here) > D=> send feedback with CLOCK option > Further packet flow continues with timer based > compression.................. > > Scenario 3: Decompressor initializes and compressor rejects > ===================================================== > Packet flow with scaled timestamp compression going on................. > D => send feedback with CLOCK option > C=> No TIME_STRIDE info is sent (indicates not wanting to switch to Timer > Based) > Further packet flow continues with scaled timestamp > compression.................. > > Scenario 4: Compressor initializes and decompressor rejects > ===================================================== > Packet flow with scaled timestamp compression going on................. > C =>send TIME_STRIDE information > D=> send feedback with CLOCK option set to zero (means no desire to do > timer based compression) > Further packet flow continues with scaled timestamp > compression.................. > > For various compressor and decompressor implementations to interoperate, > this may be the minimum set to be taken care. > > > ================================================= > When your work speaks for itself, get out of the way. > -- Thomas 'Wayne' Brazell > ================================================= > Kavitha K.R., > L&T Infotech, > Bangalore. > > ( ) L&T Infotech Proprietary & Confidential > ( ) L&T Infotech Confidential > (+) L&T Infotech Internal Use only > ( ) General Business Information > > > > "Kristofer Sandlund \(LU/EAB\)" > 01/05/2006 01:26 PM > > To > "Sarkar, Biplab" , "Kavitha KR" > > cc > > Subject > RE: [rohc] Timer-based compression > > > > > > > Hi, > > Implementer's guide section 4.3: > > Before timer-based compression can be used, the decompressor will > have to inform the compressor (on a per-channel basis) about its > clock resolution. Further, the compressor has to send (on a per- > context basis) a non-zero TIME_STRIDE to the decompressor. > > When the compressor is confident that the decompressor has received > the TIME_STRIDE value, it can switch to timer-based compression. > During this transition from window-based compression to timer-based > compression, it is necessary that the compressor keep k large enough > to cover both interpretation intervals. > > So the procedure is: > 0) TIME_STRIDE starts out as zero > 1) CLOCK option is sent by decompressor and received by compressor > 2) Compressor decides that it wants to use timer-based compression. > If so, the compressor sends a non-zero TIME_STRIDE > 3) Compressor repeats time-stride until it is _confident_ that the > decompressor has correctly received the new TIME_STRIDE. Note that > these packet are already encoded with timer-based compression since > they contain a time-stride that is non-zero. > 4) All packets sent after this that contain an encoded timestamp are > assumed to be using timer-based compression. > > The timer-based compression initialization seems to be the most frequent > question on this list, but I don't know how to improve the text in the > impl-guide any further. I thought it was quite clear now, but obviously > it still isn't good enough. Do you have any suggestions on how to > improve it further? > > BR, > Kristofer > > > rohc-bounces@ietf.org wrote: > >> Hi Kavitha, >> >> >> >> I believe with the UOR-2+ext-3 the compressor says that it >> "can" support "timer-based" compression. If the decompressor >> supports this, it can send an ACK with the CLOCK option. Once >> the compressor gets the CLOCK-opt from the decompressor it >> can change to the "timer-based" compression. But it doesn't >> let the decompressor know precisely when to start expecting >> packets compressed with "timer-based" compression. There has >> to be some way to tell the decompressor that the current >> packet is compressed with the "timer-based" compression algo. >> I don't see any flags for this in the RFC. One has to >> consider the number of packets on transit before deciding to >> change the compression algorithm after the initial negotiation. >> >> >> >> Thanks >> >> Biplab >> >> >> >> ________________________________ >> >> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf >> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM >> To: rohc@ietf.org >> Subject: Re: [rohc] Timer-based compression >> >> >> >> >> Hi, >> >> Compressor can be made to send an UOR-2 packet with ext-3 or >> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it >> begins to do Timer based Compression of TS. It is a way to >> indicate timer-based compression of TS to the decompressor. >> (Refer RFC 3095 Sec 5.7.5 Extension Formats) >> >> Kavitha K.R., >> L&T Infotech, >> Bangalore. >> >> ( ) L&T Infotech Proprietary & Confidential >> ( ) L&T Infotech Confidential >> () L&T Infotech Internal Use only >> (+) General Business Information >> >> >> >> "Sarkar, Biplab" >> Sent by: rohc-bounces@ietf.org >> >> 01/05/2006 11:41 AM >> >> To >> >> >> >> cc >> >> >> >> Subject >> >> [rohc] Timer-based compression >> >> >> >> >> >> >> >> >> >> >> All, >> >> I have a query. >> >> How does the decompressor know "from" which packet onward it >> would be getting packets encoded with >> timer-based-compression? Since the ACK from the decompressor >> which carries the CLOCK option might take some time to reach >> and get processed at the compressor; is there any way for the >> decompressor to know when to expect packets to be encoded >> with the timer-based compression method. >> >> Thanks >> Biplab >> >> ++++++++++++++++++++++++++++++++ >> Biplab Sarkar >> Starent Networks, Bangalore >> ++++++++++++++++++++++++++++++++ >> >> >> >> ______________________________________________________________ >> _______________________________________________________ >> 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 > ______________________________________________________________________ ______________________________________________________________________ --=_alternative 003074A1652570ED_= Content-Type: text/html; charset="US-ASCII"
Hi L-E/Kristofer,

But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 of 3095,

"The smallest clock resolution which can be indicated is 1
millisecond. The value zero has a special meaning: it indicates that
the decompressor cannot do timer-based compression of the RTP
Timestamp."

So even if there are impertinent Compressors (Scenario 2 and 4), Decompressors can still send CLOCK value zero and
choose not to do timer based decompression. Isn't it so ?


Regards,
Kavitha K.R.,
L&T Infotech,
Bangalore.

( ) L&T Infotech Proprietary & Confidential
( ) L&T Infotech Confidential
(+) L&T Infotech Internal Use only
( ) General Business Information


"Lars-Erik Jonsson" <larsman@home.se>

01/05/2006 02:10 PM

To
<rohc@ietf.org>, "Kavitha KR" <Kavitha.KR@lntinfotech.com>
cc
Subject
Re: [rohc] Timer-based compression





Kavitha,

As said in the implementer's guide, "Before timer-based compression can
be used, the decompressor will have to inform the compressor (on a per-
channel basis) about its clock resolution."

This means only scenario 1 and 3 make sense. The compressor is not
allowed to start timer-based compression before the decompressor has
sent the clock resolution (i.e. the CLOCK option).

BR
/L-E


----- Original Message -----
From: "Kavitha KR" <Kavitha.KR@lntinfotech.com>
To: <rohc@ietf.org>
Sent: Thursday, January 05, 2006 9:35 AM
Subject: RE: [rohc] Timer-based compression


> Hi,
>
> There could be 4 cases for switching from scaled TS compression to Timer
> based compression of RTP TS.
>
> Scenario 1 : Decompressor initializes and compressor accepts
> =====================================================
> Packet flow with scaled timestamp compression going on.................
> D => send feedback with CLOCK option
> C => send TIME_STRIDE information (timer based compression starts here)
> Further packet flow continues with timer based
> compression..................
>
> Scenario 2: Compressor initializes and decompressor accepts
> =====================================================
> Packet flow with scaled timestamp compression going on.................
> C=> send TIME_STRIDE information (timer based compression starts here)
> D=> send feedback with CLOCK option
> Further packet flow continues with timer based
> compression..................
>
> Scenario 3: Decompressor initializes and compressor rejects
> =====================================================
> Packet flow with scaled timestamp compression going on.................
> D => send feedback with CLOCK option
> C=> No TIME_STRIDE info is sent (indicates not wanting to switch to Timer
> Based)
> Further packet flow continues with scaled timestamp
> compression..................
>
> Scenario 4: Compressor initializes and decompressor rejects
> =====================================================
> Packet flow with scaled timestamp compression going on.................
> C =>send TIME_STRIDE information
> D=> send feedback with CLOCK option set to zero (means no desire to do
> timer based compression)
> Further packet flow continues with scaled timestamp
> compression..................
>
> For various compressor and decompressor implementations to interoperate,
> this may be the minimum set to be taken care.
>
>
> =================================================
> When your work speaks for itself, get out of the way.
> -- Thomas 'Wayne' Brazell
> =================================================
> Kavitha K.R.,
> L&T Infotech,
> Bangalore.
>
> ( ) L&T Infotech Proprietary & Confidential
> ( ) L&T Infotech Confidential
> (+) L&T Infotech Internal Use only
> ( ) General Business Information
>
>
>
> "Kristofer Sandlund \(LU/EAB\)" <kristofer.sandlund@ericsson.com>
> 01/05/2006 01:26 PM
>
> To
> "Sarkar, Biplab" <bsarkar@starentnetworks.com>, "Kavitha KR"
> <Kavitha.KR@lntinfotech.com>
> cc
> <rohc@ietf.org>
> Subject
> RE: [rohc] Timer-based compression
>
>
>
>
>
>
> Hi,
>
> Implementer's guide section 4.3:
>
>   Before timer-based compression can be used, the decompressor will
>   have to inform the compressor (on a per-channel basis) about its
>   clock resolution. Further, the compressor has to send (on a per-
>   context basis) a non-zero TIME_STRIDE to the decompressor.
>
>   When the compressor is confident that the decompressor has received
>   the TIME_STRIDE value, it can switch to timer-based compression.
>   During this transition from window-based compression to timer-based
>   compression, it is necessary that the compressor keep k large enough
>   to cover both interpretation intervals.
>
> So the procedure is:
> 0) TIME_STRIDE starts out as zero
> 1) CLOCK option is sent by decompressor and received by compressor
> 2) Compressor decides that it wants to use timer-based compression.
>   If so, the compressor sends a non-zero TIME_STRIDE
> 3) Compressor repeats time-stride until it is _confident_ that the
>   decompressor has correctly received the new TIME_STRIDE. Note that
>   these packet are already encoded with timer-based compression since
>   they contain a time-stride that is non-zero.
> 4) All packets sent after this that contain an encoded timestamp are
>   assumed to be using timer-based compression.
>
> The timer-based compression initialization seems to be the most frequent
> question on this list, but I don't know how to improve the text in the
> impl-guide any further. I thought it was quite clear now, but obviously
> it still isn't good enough. Do you have any suggestions on how to
> improve it further?
>
> BR,
>                 Kristofer
>
>
> rohc-bounces@ietf.org <mailto:rohc-bounces@ietf.org> wrote:
>
>> Hi Kavitha,
>>
>>
>>
>> I believe with the UOR-2+ext-3 the compressor says that it
>> "can" support "timer-based" compression. If the decompressor
>> supports this, it can send an ACK with the CLOCK option. Once
>> the compressor gets the CLOCK-opt from the decompressor it
>> can change to the "timer-based" compression. But it doesn't
>> let the decompressor know precisely when to start expecting
>> packets compressed with "timer-based" compression.  There has
>> to be some way to tell the decompressor that the current
>> packet is compressed with the "timer-based" compression algo.
>>  I don't see any flags for this in the RFC. One has to
>> consider the number of packets on transit before deciding to
>> change the compression algorithm after the initial negotiation.
>>
>>
>>
>> Thanks
>>
>> Biplab
>>
>>
>>
>> ________________________________
>>
>> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf
>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM
>> To: rohc@ietf.org
>> Subject: Re: [rohc] Timer-based compression
>>
>>
>>
>>
>> Hi,
>>
>> Compressor can be made to send an UOR-2 packet with ext-3 or
>> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it
>> begins to do Timer based Compression of TS.  It is a way to
>> indicate timer-based compression of TS to the decompressor.
>> (Refer RFC 3095 Sec 5.7.5  Extension Formats)
>>
>> Kavitha K.R.,
>> L&T Infotech,
>> Bangalore.
>>
>> ( ) L&T Infotech Proprietary & Confidential
>> ( ) L&T Infotech Confidential
>> () L&T Infotech Internal Use only
>> (+) General Business Information
>>
>>
>>
>> "Sarkar, Biplab" <bsarkar@starentnetworks.com>
>> Sent by: rohc-bounces@ietf.org
>>
>> 01/05/2006 11:41 AM
>>
>> To
>>
>> <rohc@ietf.org>
>>
>> cc
>>
>>
>>
>> Subject
>>
>> [rohc] Timer-based compression
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> All,
>>
>> I have a query.
>>
>> How does the decompressor know "from" which packet onward it
>> would be getting packets encoded with
>> timer-based-compression? Since the ACK from the decompressor
>> which carries the CLOCK option might take some time to reach
>> and get processed at the compressor; is there any way for the
>> decompressor to know when to expect packets to be encoded
>> with the timer-based compression method.
>>
>> Thanks
>> Biplab
>>
>> ++++++++++++++++++++++++++++++++
>> Biplab Sarkar
>> Starent Networks, Bangalore
>> ++++++++++++++++++++++++++++++++
>>
>>
>>
>> ______________________________________________________________
>> _______________________________________________________
>> 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
>


______________________________________________________________________

______________________________________________________________________
--=_alternative 003074A1652570ED_=-- --===============0296360585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0296360585==-- From rohc-bounces@ietf.org Thu Jan 05 03:57:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQwP-0002YF-4p; Thu, 05 Jan 2006 03:57:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQwN-0002Y7-97 for rohc@megatron.ietf.org; Thu, 05 Jan 2006 03:57:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13764 for ; Thu, 5 Jan 2006 03:56:30 -0500 (EST) Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuR20-0001I1-SO for rohc@ietf.org; Thu, 05 Jan 2006 04:03:37 -0500 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id 56AAE37E65; Thu, 5 Jan 2006 09:57:32 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3F09237E4B; Thu, 5 Jan 2006 09:57:32 +0100 (CET) Received: from jymden (81-235-131-199-no14.tbcn.telia.com [81.235.131.199]) by smtp4-1-sn2.hy.skanova.net (Postfix) with SMTP id 0310D37E47; Thu, 5 Jan 2006 09:57:31 +0100 (CET) Message-ID: <005601c611d6$2a6c6c20$6500a8c0@jymden> From: "Lars-Erik Jonsson" To: "Kavitha KR" , References: Subject: Re: [rohc] Timer-based compression Date: Thu, 5 Jan 2006 09:58:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org The decompressor can also send a CLOCK option vith value zero, but a compressor is still not allowed to start timer-based compression before it has received the CLOCK option. The specifications do not allow that, and one reason for that is the fact that the compressor can not know how to compress with timer-based compression without knowing the clock resolution. /L-E ----- Original Message ----- From: "Kavitha KR" To: Sent: Thursday, January 05, 2006 9:52 AM Subject: Re: [rohc] Timer-based compression > Hi L-E/Kristofer, > > But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 of > 3095, > > "The smallest clock resolution which can be indicated is 1 > millisecond. The value zero has a special meaning: it indicates that > the decompressor cannot do timer-based compression of the RTP > Timestamp." > > So even if there are impertinent Compressors (Scenario 2 and 4), > Decompressors can still send CLOCK value zero and > choose not to do timer based decompression. Isn't it so ? > > > Regards, > Kavitha K.R., > L&T Infotech, > Bangalore. > > ( ) L&T Infotech Proprietary & Confidential > ( ) L&T Infotech Confidential > (+) L&T Infotech Internal Use only > ( ) General Business Information > > > > "Lars-Erik Jonsson" > 01/05/2006 02:10 PM > > To > , "Kavitha KR" > cc > > Subject > Re: [rohc] Timer-based compression > > > > > > > Kavitha, > > As said in the implementer's guide, "Before timer-based compression can > be used, the decompressor will have to inform the compressor (on a per- > channel basis) about its clock resolution." > > This means only scenario 1 and 3 make sense. The compressor is not > allowed to start timer-based compression before the decompressor has > sent the clock resolution (i.e. the CLOCK option). > > BR > /L-E > > > ----- Original Message ----- > From: "Kavitha KR" > To: > Sent: Thursday, January 05, 2006 9:35 AM > Subject: RE: [rohc] Timer-based compression > > >> Hi, >> >> There could be 4 cases for switching from scaled TS compression to Timer >> based compression of RTP TS. >> >> Scenario 1 : Decompressor initializes and compressor accepts >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> D => send feedback with CLOCK option >> C => send TIME_STRIDE information (timer based compression starts here) >> Further packet flow continues with timer based >> compression.................. >> >> Scenario 2: Compressor initializes and decompressor accepts >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> C=> send TIME_STRIDE information (timer based compression starts here) >> D=> send feedback with CLOCK option >> Further packet flow continues with timer based >> compression.................. >> >> Scenario 3: Decompressor initializes and compressor rejects >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> D => send feedback with CLOCK option >> C=> No TIME_STRIDE info is sent (indicates not wanting to switch to > Timer >> Based) >> Further packet flow continues with scaled timestamp >> compression.................. >> >> Scenario 4: Compressor initializes and decompressor rejects >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> C =>send TIME_STRIDE information >> D=> send feedback with CLOCK option set to zero (means no desire to do >> timer based compression) >> Further packet flow continues with scaled timestamp >> compression.................. >> >> For various compressor and decompressor implementations to interoperate, >> this may be the minimum set to be taken care. >> >> >> ================================================= >> When your work speaks for itself, get out of the way. >> -- Thomas 'Wayne' Brazell >> ================================================= >> Kavitha K.R., >> L&T Infotech, >> Bangalore. >> >> ( ) L&T Infotech Proprietary & Confidential >> ( ) L&T Infotech Confidential >> (+) L&T Infotech Internal Use only >> ( ) General Business Information >> >> >> >> "Kristofer Sandlund \(LU/EAB\)" >> 01/05/2006 01:26 PM >> >> To >> "Sarkar, Biplab" , "Kavitha KR" >> >> cc >> >> Subject >> RE: [rohc] Timer-based compression >> >> >> >> >> >> >> Hi, >> >> Implementer's guide section 4.3: >> >> Before timer-based compression can be used, the decompressor will >> have to inform the compressor (on a per-channel basis) about its >> clock resolution. Further, the compressor has to send (on a per- >> context basis) a non-zero TIME_STRIDE to the decompressor. >> >> When the compressor is confident that the decompressor has received >> the TIME_STRIDE value, it can switch to timer-based compression. >> During this transition from window-based compression to timer-based >> compression, it is necessary that the compressor keep k large enough >> to cover both interpretation intervals. >> >> So the procedure is: >> 0) TIME_STRIDE starts out as zero >> 1) CLOCK option is sent by decompressor and received by compressor >> 2) Compressor decides that it wants to use timer-based compression. >> If so, the compressor sends a non-zero TIME_STRIDE >> 3) Compressor repeats time-stride until it is _confident_ that the >> decompressor has correctly received the new TIME_STRIDE. Note that >> these packet are already encoded with timer-based compression since >> they contain a time-stride that is non-zero. >> 4) All packets sent after this that contain an encoded timestamp are >> assumed to be using timer-based compression. >> >> The timer-based compression initialization seems to be the most frequent >> question on this list, but I don't know how to improve the text in the >> impl-guide any further. I thought it was quite clear now, but obviously >> it still isn't good enough. Do you have any suggestions on how to >> improve it further? >> >> BR, >> Kristofer >> >> >> rohc-bounces@ietf.org wrote: >> >>> Hi Kavitha, >>> >>> >>> >>> I believe with the UOR-2+ext-3 the compressor says that it >>> "can" support "timer-based" compression. If the decompressor >>> supports this, it can send an ACK with the CLOCK option. Once >>> the compressor gets the CLOCK-opt from the decompressor it >>> can change to the "timer-based" compression. But it doesn't >>> let the decompressor know precisely when to start expecting >>> packets compressed with "timer-based" compression. There has >>> to be some way to tell the decompressor that the current >>> packet is compressed with the "timer-based" compression algo. >>> I don't see any flags for this in the RFC. One has to >>> consider the number of packets on transit before deciding to >>> change the compression algorithm after the initial negotiation. >>> >>> >>> >>> Thanks >>> >>> Biplab >>> >>> >>> >>> ________________________________ >>> >>> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf >>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM >>> To: rohc@ietf.org >>> Subject: Re: [rohc] Timer-based compression >>> >>> >>> >>> >>> Hi, >>> >>> Compressor can be made to send an UOR-2 packet with ext-3 or >>> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it >>> begins to do Timer based Compression of TS. It is a way to >>> indicate timer-based compression of TS to the decompressor. >>> (Refer RFC 3095 Sec 5.7.5 Extension Formats) >>> >>> Kavitha K.R., >>> L&T Infotech, >>> Bangalore. >>> >>> ( ) L&T Infotech Proprietary & Confidential >>> ( ) L&T Infotech Confidential >>> () L&T Infotech Internal Use only >>> (+) General Business Information >>> >>> >>> >>> "Sarkar, Biplab" >>> Sent by: rohc-bounces@ietf.org >>> >>> 01/05/2006 11:41 AM >>> >>> To >>> >>> >>> >>> cc >>> >>> >>> >>> Subject >>> >>> [rohc] Timer-based compression >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> All, >>> >>> I have a query. >>> >>> How does the decompressor know "from" which packet onward it >>> would be getting packets encoded with >>> timer-based-compression? Since the ACK from the decompressor >>> which carries the CLOCK option might take some time to reach >>> and get processed at the compressor; is there any way for the >>> decompressor to know when to expect packets to be encoded >>> with the timer-based compression method. >>> >>> Thanks >>> Biplab >>> >>> ++++++++++++++++++++++++++++++++ >>> Biplab Sarkar >>> Starent Networks, Bangalore >>> ++++++++++++++++++++++++++++++++ >>> >>> >>> >>> ______________________________________________________________ >>> _______________________________________________________ >>> Rohc mailing list >>> Rohc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rohc >>> >>> >>> ______________________________________________________________________ >> >> >> ______________________________________________________________________ >> >> >> >> ______________________________________________________________________ > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> Rohc mailing list >> Rohc@ietf.org >> https://www1.ietf.org/mailman/listinfo/rohc >> > > > ______________________________________________________________________ > > > > ______________________________________________________________________ -------------------------------------------------------------------------------- > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 05 04:24:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRM0-0001pF-3I; Thu, 05 Jan 2006 04:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRLx-0001ni-NA for rohc@megatron.ietf.org; Thu, 05 Jan 2006 04:24:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16453 for ; Thu, 5 Jan 2006 04:22:57 -0500 (EST) Received: from mail43.messagelabs.com ([216.82.255.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuRRb-0002Bz-Lz for rohc@ietf.org; Thu, 05 Jan 2006 04:30:04 -0500 X-VirusChecked: Checked X-Env-Sender: Kavitha.KR@lntinfotech.com X-Msg-Ref: server-15.tower-43.messagelabs.com!1136453038!29685272!2 X-StarScan-Version: 5.5.9.1; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 15702 invoked from network); 5 Jan 2006 09:24:00 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-15.tower-43.messagelabs.com with SMTP; 5 Jan 2006 09:24:00 -0000 Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006010514535805-12926 ; Thu, 5 Jan 2006 14:53:58 +0530 In-Reply-To: <005601c611d6$2a6c6c20$6500a8c0@jymden> To: rohc@ietf.org Subject: Re: [rohc] Timer-based compression MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Kavitha KR Date: Thu, 5 Jan 2006 14:57:52 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:57:52 PM, Serialize complete at 01/05/2006 02:57:52 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:53:58 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 01/05/2006 02:54:00 PM, Serialize complete at 01/05/2006 02:54:00 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a1acaa54b4cde5ab4439a319e9b7f91 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1374540907==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multipart message in MIME format. --===============1374540907== Content-Type: multipart/alternative; boundary="=_alternative 0033A71D652570ED_=" This is a multipart message in MIME format. --=_alternative 0033A71D652570ED_= Content-Type: text/plain; charset="US-ASCII" Okay. Then this means only decompressor can initiate timer based decompression. And for that it sends a feedback with CLOCK option. If a decompressor does not want to do timer based compression, it would just not send a CLOCK option at all. Then when does the decompressor send a CLOCK option with value zero ? This 'special meaning' thing in CLOCK option (Sec 5.7.6.7) looks a bit misleading. BR, Kavitha K.R., L&T Infotech, Bangalore. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information "Lars-Erik Jonsson" 01/05/2006 02:28 PM To "Kavitha KR" , cc Subject Re: [rohc] Timer-based compression The decompressor can also send a CLOCK option vith value zero, but a compressor is still not allowed to start timer-based compression before it has received the CLOCK option. The specifications do not allow that, and one reason for that is the fact that the compressor can not know how to compress with timer-based compression without knowing the clock resolution. /L-E ----- Original Message ----- From: "Kavitha KR" To: Sent: Thursday, January 05, 2006 9:52 AM Subject: Re: [rohc] Timer-based compression > Hi L-E/Kristofer, > > But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 of > 3095, > > "The smallest clock resolution which can be indicated is 1 > millisecond. The value zero has a special meaning: it indicates that > the decompressor cannot do timer-based compression of the RTP > Timestamp." > > So even if there are impertinent Compressors (Scenario 2 and 4), > Decompressors can still send CLOCK value zero and > choose not to do timer based decompression. Isn't it so ? > > > Regards, > Kavitha K.R., > L&T Infotech, > Bangalore. > > ( ) L&T Infotech Proprietary & Confidential > ( ) L&T Infotech Confidential > (+) L&T Infotech Internal Use only > ( ) General Business Information > > > > "Lars-Erik Jonsson" > 01/05/2006 02:10 PM > > To > , "Kavitha KR" > cc > > Subject > Re: [rohc] Timer-based compression > > > > > > > Kavitha, > > As said in the implementer's guide, "Before timer-based compression can > be used, the decompressor will have to inform the compressor (on a per- > channel basis) about its clock resolution." > > This means only scenario 1 and 3 make sense. The compressor is not > allowed to start timer-based compression before the decompressor has > sent the clock resolution (i.e. the CLOCK option). > > BR > /L-E > > > ----- Original Message ----- > From: "Kavitha KR" > To: > Sent: Thursday, January 05, 2006 9:35 AM > Subject: RE: [rohc] Timer-based compression > > >> Hi, >> >> There could be 4 cases for switching from scaled TS compression to Timer >> based compression of RTP TS. >> >> Scenario 1 : Decompressor initializes and compressor accepts >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> D => send feedback with CLOCK option >> C => send TIME_STRIDE information (timer based compression starts here) >> Further packet flow continues with timer based >> compression.................. >> >> Scenario 2: Compressor initializes and decompressor accepts >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> C=> send TIME_STRIDE information (timer based compression starts here) >> D=> send feedback with CLOCK option >> Further packet flow continues with timer based >> compression.................. >> >> Scenario 3: Decompressor initializes and compressor rejects >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> D => send feedback with CLOCK option >> C=> No TIME_STRIDE info is sent (indicates not wanting to switch to > Timer >> Based) >> Further packet flow continues with scaled timestamp >> compression.................. >> >> Scenario 4: Compressor initializes and decompressor rejects >> ===================================================== >> Packet flow with scaled timestamp compression going on................. >> C =>send TIME_STRIDE information >> D=> send feedback with CLOCK option set to zero (means no desire to do >> timer based compression) >> Further packet flow continues with scaled timestamp >> compression.................. >> >> For various compressor and decompressor implementations to interoperate, >> this may be the minimum set to be taken care. >> >> >> ================================================= >> When your work speaks for itself, get out of the way. >> -- Thomas 'Wayne' Brazell >> ================================================= >> Kavitha K.R., >> L&T Infotech, >> Bangalore. >> >> ( ) L&T Infotech Proprietary & Confidential >> ( ) L&T Infotech Confidential >> (+) L&T Infotech Internal Use only >> ( ) General Business Information >> >> >> >> "Kristofer Sandlund \(LU/EAB\)" >> 01/05/2006 01:26 PM >> >> To >> "Sarkar, Biplab" , "Kavitha KR" >> >> cc >> >> Subject >> RE: [rohc] Timer-based compression >> >> >> >> >> >> >> Hi, >> >> Implementer's guide section 4.3: >> >> Before timer-based compression can be used, the decompressor will >> have to inform the compressor (on a per-channel basis) about its >> clock resolution. Further, the compressor has to send (on a per- >> context basis) a non-zero TIME_STRIDE to the decompressor. >> >> When the compressor is confident that the decompressor has received >> the TIME_STRIDE value, it can switch to timer-based compression. >> During this transition from window-based compression to timer-based >> compression, it is necessary that the compressor keep k large enough >> to cover both interpretation intervals. >> >> So the procedure is: >> 0) TIME_STRIDE starts out as zero >> 1) CLOCK option is sent by decompressor and received by compressor >> 2) Compressor decides that it wants to use timer-based compression. >> If so, the compressor sends a non-zero TIME_STRIDE >> 3) Compressor repeats time-stride until it is _confident_ that the >> decompressor has correctly received the new TIME_STRIDE. Note that >> these packet are already encoded with timer-based compression since >> they contain a time-stride that is non-zero. >> 4) All packets sent after this that contain an encoded timestamp are >> assumed to be using timer-based compression. >> >> The timer-based compression initialization seems to be the most frequent >> question on this list, but I don't know how to improve the text in the >> impl-guide any further. I thought it was quite clear now, but obviously >> it still isn't good enough. Do you have any suggestions on how to >> improve it further? >> >> BR, >> Kristofer >> >> >> rohc-bounces@ietf.org wrote: >> >>> Hi Kavitha, >>> >>> >>> >>> I believe with the UOR-2+ext-3 the compressor says that it >>> "can" support "timer-based" compression. If the decompressor >>> supports this, it can send an ACK with the CLOCK option. Once >>> the compressor gets the CLOCK-opt from the decompressor it >>> can change to the "timer-based" compression. But it doesn't >>> let the decompressor know precisely when to start expecting >>> packets compressed with "timer-based" compression. There has >>> to be some way to tell the decompressor that the current >>> packet is compressed with the "timer-based" compression algo. >>> I don't see any flags for this in the RFC. One has to >>> consider the number of packets on transit before deciding to >>> change the compression algorithm after the initial negotiation. >>> >>> >>> >>> Thanks >>> >>> Biplab >>> >>> >>> >>> ________________________________ >>> >>> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf >>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM >>> To: rohc@ietf.org >>> Subject: Re: [rohc] Timer-based compression >>> >>> >>> >>> >>> Hi, >>> >>> Compressor can be made to send an UOR-2 packet with ext-3 or >>> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it >>> begins to do Timer based Compression of TS. It is a way to >>> indicate timer-based compression of TS to the decompressor. >>> (Refer RFC 3095 Sec 5.7.5 Extension Formats) >>> >>> Kavitha K.R., >>> L&T Infotech, >>> Bangalore. >>> >>> ( ) L&T Infotech Proprietary & Confidential >>> ( ) L&T Infotech Confidential >>> () L&T Infotech Internal Use only >>> (+) General Business Information >>> >>> >>> >>> "Sarkar, Biplab" >>> Sent by: rohc-bounces@ietf.org >>> >>> 01/05/2006 11:41 AM >>> >>> To >>> >>> >>> >>> cc >>> >>> >>> >>> Subject >>> >>> [rohc] Timer-based compression >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> All, >>> >>> I have a query. >>> >>> How does the decompressor know "from" which packet onward it >>> would be getting packets encoded with >>> timer-based-compression? Since the ACK from the decompressor >>> which carries the CLOCK option might take some time to reach >>> and get processed at the compressor; is there any way for the >>> decompressor to know when to expect packets to be encoded >>> with the timer-based compression method. >>> >>> Thanks >>> Biplab >>> >>> ++++++++++++++++++++++++++++++++ >>> Biplab Sarkar >>> Starent Networks, Bangalore >>> ++++++++++++++++++++++++++++++++ >>> >>> >>> >>> ______________________________________________________________ >>> _______________________________________________________ >>> 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 > ______________________________________________________________________ ______________________________________________________________________ --=_alternative 0033A71D652570ED_= Content-Type: text/html; charset="US-ASCII"
Okay. Then this means only decompressor can initiate timer based decompression.
And for that it sends a feedback with CLOCK option.

If a decompressor does not want to do timer based compression, it would just not send a  CLOCK option at all.
Then when does the decompressor  send a CLOCK option with value zero ?
This 'special meaning' thing in CLOCK option (Sec 5.7.6.7)  looks a bit misleading.

BR,
Kavitha K.R.,
L&T Infotech,
Bangalore.

( ) L&T Infotech Proprietary & Confidential
( ) L&T Infotech Confidential
(+) L&T Infotech Internal Use only
( ) General Business Information


"Lars-Erik Jonsson" <larsman@home.se>

01/05/2006 02:28 PM

To
"Kavitha KR" <Kavitha.KR@lntinfotech.com>, <rohc@ietf.org>
cc
Subject
Re: [rohc] Timer-based compression





The decompressor can also send a CLOCK option vith value zero, but
a compressor is still not allowed to start timer-based compression before
it has received the CLOCK option. The specifications do not allow that,
and one reason for that is the fact that the compressor can not know how
to compress with timer-based compression without knowing the clock
resolution.

/L-E


----- Original Message -----
From: "Kavitha KR" <Kavitha.KR@lntinfotech.com>
To: <rohc@ietf.org>
Sent: Thursday, January 05, 2006 9:52 AM
Subject: Re: [rohc] Timer-based compression


> Hi L-E/Kristofer,
>
> But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 of
> 3095,
>
> "The smallest clock resolution which can be indicated is 1
> millisecond. The value zero has a special meaning: it indicates that
> the decompressor cannot do timer-based compression of the RTP
> Timestamp."
>
> So even if there are impertinent Compressors (Scenario 2 and 4),
> Decompressors can still send CLOCK value zero and
> choose not to do timer based decompression. Isn't it so ?
>
>
> Regards,
> Kavitha K.R.,
> L&T Infotech,
> Bangalore.
>
> ( ) L&T Infotech Proprietary & Confidential
> ( ) L&T Infotech Confidential
> (+) L&T Infotech Internal Use only
> ( ) General Business Information
>
>
>
> "Lars-Erik Jonsson" <larsman@home.se>
> 01/05/2006 02:10 PM
>
> To
> <rohc@ietf.org>, "Kavitha KR" <Kavitha.KR@lntinfotech.com>
> cc
>
> Subject
> Re: [rohc] Timer-based compression
>
>
>
>
>
>
> Kavitha,
>
> As said in the implementer's guide, "Before timer-based compression can
> be used, the decompressor will have to inform the compressor (on a per-
> channel basis) about its clock resolution."
>
> This means only scenario 1 and 3 make sense. The compressor is not
> allowed to start timer-based compression before the decompressor has
> sent the clock resolution (i.e. the CLOCK option).
>
> BR
> /L-E
>
>
> ----- Original Message -----
> From: "Kavitha KR" <Kavitha.KR@lntinfotech.com>
> To: <rohc@ietf.org>
> Sent: Thursday, January 05, 2006 9:35 AM
> Subject: RE: [rohc] Timer-based compression
>
>
>> Hi,
>>
>> There could be 4 cases for switching from scaled TS compression to Timer
>> based compression of RTP TS.
>>
>> Scenario 1 : Decompressor initializes and compressor accepts
>> =====================================================
>> Packet flow with scaled timestamp compression going on.................
>> D => send feedback with CLOCK option
>> C => send TIME_STRIDE information (timer based compression starts here)
>> Further packet flow continues with timer based
>> compression..................
>>
>> Scenario 2: Compressor initializes and decompressor accepts
>> =====================================================
>> Packet flow with scaled timestamp compression going on.................
>> C=> send TIME_STRIDE information (timer based compression starts here)
>> D=> send feedback with CLOCK option
>> Further packet flow continues with timer based
>> compression..................
>>
>> Scenario 3: Decompressor initializes and compressor rejects
>> =====================================================
>> Packet flow with scaled timestamp compression going on.................
>> D => send feedback with CLOCK option
>> C=> No TIME_STRIDE info is sent (indicates not wanting to switch to
> Timer
>> Based)
>> Further packet flow continues with scaled timestamp
>> compression..................
>>
>> Scenario 4: Compressor initializes and decompressor rejects
>> =====================================================
>> Packet flow with scaled timestamp compression going on.................
>> C =>send TIME_STRIDE information
>> D=> send feedback with CLOCK option set to zero (means no desire to do
>> timer based compression)
>> Further packet flow continues with scaled timestamp
>> compression..................
>>
>> For various compressor and decompressor implementations to interoperate,
>> this may be the minimum set to be taken care.
>>
>>
>> =================================================
>> When your work speaks for itself, get out of the way.
>> -- Thomas 'Wayne' Brazell
>> =================================================
>> Kavitha K.R.,
>> L&T Infotech,
>> Bangalore.
>>
>> ( ) L&T Infotech Proprietary & Confidential
>> ( ) L&T Infotech Confidential
>> (+) L&T Infotech Internal Use only
>> ( ) General Business Information
>>
>>
>>
>> "Kristofer Sandlund \(LU/EAB\)" <kristofer.sandlund@ericsson.com>
>> 01/05/2006 01:26 PM
>>
>> To
>> "Sarkar, Biplab" <bsarkar@starentnetworks.com>, "Kavitha KR"
>> <Kavitha.KR@lntinfotech.com>
>> cc
>> <rohc@ietf.org>
>> Subject
>> RE: [rohc] Timer-based compression
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>> Implementer's guide section 4.3:
>>
>>   Before timer-based compression can be used, the decompressor will
>>   have to inform the compressor (on a per-channel basis) about its
>>   clock resolution. Further, the compressor has to send (on a per-
>>   context basis) a non-zero TIME_STRIDE to the decompressor.
>>
>>   When the compressor is confident that the decompressor has received
>>   the TIME_STRIDE value, it can switch to timer-based compression.
>>   During this transition from window-based compression to timer-based
>>   compression, it is necessary that the compressor keep k large enough
>>   to cover both interpretation intervals.
>>
>> So the procedure is:
>> 0) TIME_STRIDE starts out as zero
>> 1) CLOCK option is sent by decompressor and received by compressor
>> 2) Compressor decides that it wants to use timer-based compression.
>>   If so, the compressor sends a non-zero TIME_STRIDE
>> 3) Compressor repeats time-stride until it is _confident_ that the
>>   decompressor has correctly received the new TIME_STRIDE. Note that
>>   these packet are already encoded with timer-based compression since
>>   they contain a time-stride that is non-zero.
>> 4) All packets sent after this that contain an encoded timestamp are
>>   assumed to be using timer-based compression.
>>
>> The timer-based compression initialization seems to be the most frequent
>> question on this list, but I don't know how to improve the text in the
>> impl-guide any further. I thought it was quite clear now, but obviously
>> it still isn't good enough. Do you have any suggestions on how to
>> improve it further?
>>
>> BR,
>>                 Kristofer
>>
>>
>> rohc-bounces@ietf.org <mailto:rohc-bounces@ietf.org> wrote:
>>
>>> Hi Kavitha,
>>>
>>>
>>>
>>> I believe with the UOR-2+ext-3 the compressor says that it
>>> "can" support "timer-based" compression. If the decompressor
>>> supports this, it can send an ACK with the CLOCK option. Once
>>> the compressor gets the CLOCK-opt from the decompressor it
>>> can change to the "timer-based" compression. But it doesn't
>>> let the decompressor know precisely when to start expecting
>>> packets compressed with "timer-based" compression.  There has
>>> to be some way to tell the decompressor that the current
>>> packet is compressed with the "timer-based" compression algo.
>>>  I don't see any flags for this in the RFC. One has to
>>> consider the number of packets on transit before deciding to
>>> change the compression algorithm after the initial negotiation.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Biplab
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf
>>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM
>>> To: rohc@ietf.org
>>> Subject: Re: [rohc] Timer-based compression
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> Compressor can be made to send an UOR-2 packet with ext-3 or
>>> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it
>>> begins to do Timer based Compression of TS.  It is a way to
>>> indicate timer-based compression of TS to the decompressor.
>>> (Refer RFC 3095 Sec 5.7.5  Extension Formats)
>>>
>>> Kavitha K.R.,
>>> L&T Infotech,
>>> Bangalore.
>>>
>>> ( ) L&T Infotech Proprietary & Confidential
>>> ( ) L&T Infotech Confidential
>>> () L&T Infotech Internal Use only
>>> (+) General Business Information
>>>
>>>
>>>
>>> "Sarkar, Biplab" <bsarkar@starentnetworks.com>
>>> Sent by: rohc-bounces@ietf.org
>>>
>>> 01/05/2006 11:41 AM
>>>
>>> To
>>>
>>> <rohc@ietf.org>
>>>
>>> cc
>>>
>>>
>>>
>>> Subject
>>>
>>> [rohc] Timer-based compression
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> All,
>>>
>>> I have a query.
>>>
>>> How does the decompressor know "from" which packet onward it
>>> would be getting packets encoded with
>>> timer-based-compression? Since the ACK from the decompressor
>>> which carries the CLOCK option might take some time to reach
>>> and get processed at the compressor; is there any way for the
>>> decompressor to know when to expect packets to be encoded
>>> with the timer-based compression method.
>>>
>>> Thanks
>>> Biplab
>>>
>>> ++++++++++++++++++++++++++++++++
>>> Biplab Sarkar
>>> Starent Networks, Bangalore
>>> ++++++++++++++++++++++++++++++++
>>>
>>>
>>>
>>> ______________________________________________________________
>>> _______________________________________________________
>>> 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
>


______________________________________________________________________

______________________________________________________________________
--=_alternative 0033A71D652570ED_=-- --===============1374540907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1374540907==-- From rohc-bounces@ietf.org Thu Jan 05 04:32:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRUB-0005lO-1g; Thu, 05 Jan 2006 04:32:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRU8-0005if-Ss for rohc@megatron.ietf.org; Thu, 05 Jan 2006 04:32:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17324 for ; Thu, 5 Jan 2006 04:31:24 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuRZi-0002W0-QW for rohc@ietf.org; Thu, 05 Jan 2006 04:38:32 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2A87DA40; Thu, 5 Jan 2006 10:31:47 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 10:31:47 +0100 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 10:31:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Timer-based compression Date: Thu, 5 Jan 2006 10:31:45 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502104BBE@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Timer-based compression Thread-Index: AcYR2f9O0qZn+/ovSoWi6BZWiOjNBwAADStQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kavitha KR" , X-OriginalArrivalTime: 05 Jan 2006 09:31:46.0651 (UTC) FILETIME=[D8EBC2B0:01C611DA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org > Okay. Then this means only decompressor can initiate timer > based decompression. > And for that it sends a feedback with CLOCK option. Well, yes, the decompressor has to let the compressor know that it supports it, and with what clock resolution. Then it is the compressor who actually initiates it. =20 > If a decompressor does not want to do timer based > compression, it would just not send a CLOCK option at all. > Then when does the decompressor send a CLOCK option with > value zero ? > This 'special meaning' thing in CLOCK option (Sec 5.7.6.7) > looks a bit misleading. Yes, it seems so. I believe the idea was (as often when 3095 was written) to provide tools that could later be found to be useful, here to give the decompressor means to explicitly tell the compressor it does not do timer-based compression (while it actually is of no practical use to do so). Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 05 04:44:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRfQ-0000mC-Fw; Thu, 05 Jan 2006 04:44:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRfO-0000j6-Dn for rohc@megatron.ietf.org; Thu, 05 Jan 2006 04:44:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18666 for ; Thu, 5 Jan 2006 04:43:03 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuRl2-0002s2-IO for rohc@ietf.org; Thu, 05 Jan 2006 04:50:09 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D4B5D4F0002; Thu, 5 Jan 2006 10:44:13 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 10:44:13 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 10:44:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Timer-based compression Date: Thu, 5 Jan 2006 10:42:00 +0100 Message-ID: Thread-Topic: [rohc] Timer-based compression Thread-Index: AcYR2bBcDMhtAV5hQCe1nnG9SV7hmgAAblWw From: "Kristofer Sandlund \(LU/EAB\)" To: "Kavitha KR" , X-OriginalArrivalTime: 05 Jan 2006 09:44:13.0451 (UTC) FILETIME=[960C65B0:01C611DC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org rohc-bounces@ietf.org wrote: > Okay. Then this means only decompressor can initiate timer > based decompression. > And for that it sends a feedback with CLOCK option. Correct. >=20 > If a decompressor does not want to do timer based > compression, it would just not send a CLOCK option at all. > Then when does the decompressor send a CLOCK option with > value zero ? > This 'special meaning' thing in CLOCK option (Sec 5.7.6.7) > looks a bit misleading. It's not exactly the first time 3095 is misleading :) I guess there could be some bizarre usage where the decompressor once has indicated a CLOCK, and then suddenly decides that it no longer wants to support this. I guess you could use this in such an event and force the compressor to re-set TIME_STRIDE to zero. But one simple solution is to just not use it! /Kristofer >=20 > BR, > Kavitha K.R., > L&T Infotech, > Bangalore. >=20 > ( ) L&T Infotech Proprietary & Confidential > ( ) L&T Infotech Confidential > (+) L&T Infotech Internal Use only > ( ) General Business Information >=20 >=20 >=20 > "Lars-Erik Jonsson" >=20 > 01/05/2006 02:28 PM To > "Kavitha KR" , > cc > Subject > Re: [rohc] Timer-based compression >=20 >=20 >=20 >=20 >=20 >=20 > The decompressor can also send a CLOCK option vith value zero, but > a compressor is still not allowed to start timer-based compression > before it has received the CLOCK option. The specifications do not > allow that, > and one reason for that is the fact that the compressor can > not know how > to compress with timer-based compression without knowing the clock > resolution.=20 >=20 > /L-E >=20 >=20 > ----- Original Message ----- > From: "Kavitha KR" > To: > Sent: Thursday, January 05, 2006 9:52 AM > Subject: Re: [rohc] Timer-based compression >=20 >=20 >> Hi L-E/Kristofer, >>=20 >> But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 >> of 3095,=20 >>=20 >> "The smallest clock resolution which can be indicated is 1 >> millisecond. The value zero has a special meaning: it indicates that >> the decompressor cannot do timer-based compression of the RTP >> Timestamp."=20 >>=20 >> So even if there are impertinent Compressors (Scenario 2 and 4), >> Decompressors can still send CLOCK value zero and >> choose not to do timer based decompression. Isn't it so ? >>=20 >>=20 >> Regards, >> Kavitha K.R., >> L&T Infotech, >> Bangalore. >>=20 >> ( ) L&T Infotech Proprietary & Confidential >> ( ) L&T Infotech Confidential >> (+) L&T Infotech Internal Use only >> ( ) General Business Information >>=20 >>=20 >>=20 >> "Lars-Erik Jonsson" >> 01/05/2006 02:10 PM >>=20 >> To >> , "Kavitha KR" >> cc >>=20 >> Subject >> Re: [rohc] Timer-based compression >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Kavitha, >>=20 >> As said in the implementer's guide, "Before timer-based compression >> can be used, the decompressor will have to inform the compressor (on >> a per- channel basis) about its clock resolution." >>=20 >> This means only scenario 1 and 3 make sense. The compressor is not >> allowed to start timer-based compression before the decompressor has >> sent the clock resolution (i.e. the CLOCK option). >>=20 >> BR >> /L-E >>=20 >>=20 >> ----- Original Message ----- >> From: "Kavitha KR" >> To: >> Sent: Thursday, January 05, 2006 9:35 AM >> Subject: RE: [rohc] Timer-based compression >>=20 >>=20 >>> Hi, >>>=20 >>> There could be 4 cases for switching from scaled TS compression to >>> Timer based compression of RTP TS.=20 >>>=20 >>> Scenario 1 : Decompressor initializes and compressor accepts >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> Packet flow with scaled timestamp compression going >>> on................. D =3D> send feedback with CLOCK option >>> C =3D> send TIME_STRIDE information (timer based compression starts >>> here) Further packet flow continues with timer based >>> compression.................. >>>=20 >>> Scenario 2: Compressor initializes and decompressor accepts >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> Packet flow with scaled timestamp compression going >>> on................. C=3D> send TIME_STRIDE information (timer based >>> compression starts here) D=3D> send feedback with CLOCK option >>> Further packet flow continues with timer based >>> compression.................. >>>=20 >>> Scenario 3: Decompressor initializes and compressor rejects >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> Packet flow with scaled timestamp compression going >>> on................. D =3D> send feedback with CLOCK option >>> C=3D> No TIME_STRIDE info is sent (indicates not wanting to switch = to >>> Timer Based) Further packet flow continues with scaled timestamp >>> compression..................=20 >>>=20 >>> Scenario 4: Compressor initializes and decompressor rejects >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> Packet flow with scaled timestamp compression going >>> on................. C =3D>send TIME_STRIDE information >>> D=3D> send feedback with CLOCK option set to zero (means no desire = to >>> do timer based compression) Further packet flow continues with >>> scaled timestamp compression..................=20 >>>=20 >>> For various compressor and decompressor implementations to >>> interoperate, this may be the minimum set to be taken care. >>>=20 >>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> When your work speaks for itself, get out of the way. -- Thomas >>> 'Wayne' Brazell = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Kavitha K.R., >>> L&T Infotech, >>> Bangalore. >>>=20 >>> ( ) L&T Infotech Proprietary & Confidential >>> ( ) L&T Infotech Confidential >>> (+) L&T Infotech Internal Use only >>> ( ) General Business Information >>>=20 >>>=20 >>>=20 >>> "Kristofer Sandlund \(LU/EAB\)" >>> 01/05/2006 01:26 PM=20 >>>=20 >>> To >>> "Sarkar, Biplab" , "Kavitha KR" >>> cc >>> >>> Subject >>> RE: [rohc] Timer-based compression >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Hi, >>>=20 >>> Implementer's guide section 4.3: >>>=20 >>> Before timer-based compression can be used, the decompressor will >>> have to inform the compressor (on a per-channel basis) about its >>> clock resolution. Further, the compressor has to send (on a per- >>> context basis) a non-zero TIME_STRIDE to the decompressor. >>>=20 >>> When the compressor is confident that the decompressor has >>> received the TIME_STRIDE value, it can switch to timer-based >>> compression. During this transition from window-based compression >>> to timer-based compression, it is necessary that the compressor >>> keep k large enough to cover both interpretation intervals. >>>=20 >>> So the procedure is: >>> 0) TIME_STRIDE starts out as zero >>> 1) CLOCK option is sent by decompressor and received by compressor >>> 2) Compressor decides that it wants to use timer-based compression. >>> If so, the compressor sends a non-zero TIME_STRIDE >>> 3) Compressor repeats time-stride until it is _confident_ that the >>> decompressor has correctly received the new TIME_STRIDE. Note that >>> these packet are already encoded with timer-based compression >>> since they contain a time-stride that is non-zero. >>> 4) All packets sent after this that contain an encoded timestamp are >>> assumed to be using timer-based compression. >>>=20 >>> The timer-based compression initialization seems to be the most >>> frequent question on this list, but I don't know how to improve the >>> text in the impl-guide any further. I thought it was quite clear >>> now, but obviously it still isn't good enough. Do you have any >>> suggestions on how to improve it further?=20 >>>=20 >>> BR, >>> Kristofer >>>=20 >>>=20 >>> rohc-bounces@ietf.org wrote: >>>=20 >>>> Hi Kavitha, >>>>=20 >>>>=20 >>>>=20 >>>> I believe with the UOR-2+ext-3 the compressor says that it >>>> "can" support "timer-based" compression. If the decompressor >>>> supports this, it can send an ACK with the CLOCK option. Once >>>> the compressor gets the CLOCK-opt from the decompressor it >>>> can change to the "timer-based" compression. But it doesn't >>>> let the decompressor know precisely when to start expecting >>>> packets compressed with "timer-based" compression. There has >>>> to be some way to tell the decompressor that the current >>>> packet is compressed with the "timer-based" compression algo. >>>> I don't see any flags for this in the RFC. One has to >>>> consider the number of packets on transit before deciding to >>>> change the compression algorithm after the initial negotiation. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>> Biplab >>>>=20 >>>>=20 >>>>=20 >>>> ________________________________ >>>>=20 >>>> From: rohc-bounces@ietf.org > [mailto:rohc-bounces@ietf.org] On Behalf >>>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM >>>> To: rohc@ietf.org >>>> Subject: Re: [rohc] Timer-based compression >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Compressor can be made to send an UOR-2 packet with ext-3 or >>>> IR/IR-DYN packet with TIS=3D1 and TIME_STRIDE value before it >>>> begins to do Timer based Compression of TS. It is a way to >>>> indicate timer-based compression of TS to the decompressor. >>>> (Refer RFC 3095 Sec 5.7.5 Extension Formats) >>>>=20 >>>> Kavitha K.R., >>>> L&T Infotech, >>>> Bangalore. >>>>=20 >>>> ( ) L&T Infotech Proprietary & Confidential >>>> ( ) L&T Infotech Confidential >>>> () L&T Infotech Internal Use only >>>> (+) General Business Information >>>>=20 >>>>=20 >>>>=20 >>>> "Sarkar, Biplab" >>>> Sent by: rohc-bounces@ietf.org >>>>=20 >>>> 01/05/2006 11:41 AM >>>>=20 >>>> To >>>>=20 >>>> >>>>=20 >>>> cc >>>>=20 >>>>=20 >>>>=20 >>>> Subject >>>>=20 >>>> [rohc] Timer-based compression >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> All, >>>>=20 >>>> I have a query. >>>>=20 >>>> How does the decompressor know "from" which packet onward it >>>> would be getting packets encoded with >>>> timer-based-compression? Since the ACK from the decompressor >>>> which carries the CLOCK option might take some time to reach >>>> and get processed at the compressor; is there any way for the >>>> decompressor to know when to expect packets to be encoded >>>> with the timer-based compression method. >>>>=20 >>>> Thanks >>>> Biplab >>>>=20 >>>> ++++++++++++++++++++++++++++++++ >>>> Biplab Sarkar >>>> Starent Networks, Bangalore >>>> ++++++++++++++++++++++++++++++++ >>>>=20 >>>>=20 >>>>=20 >>>> ______________________________________________________________ >>>> _______________________________________________________ >>>> Rohc mailing list >>>> Rohc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/rohc >>>>=20 >>>>=20 >>>>=20 > ______________________________________________________________________ >>>=20 >>>=20 >>>=20 > ______________________________________________________________________ >>>=20 >>>=20 >>>=20 >>>=20 > ______________________________________________________________________ >>=20 >>=20 >>=20 > -------------------------------------------------------------- > ------------------ >>=20 >>=20 >>> _______________________________________________ >>> Rohc mailing list >>> Rohc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rohc >>>=20 >>=20 >>=20 >>=20 > ______________________________________________________________________ >>=20 >>=20 >>=20 >>=20 > ______________________________________________________________________ >=20 >=20 > -------------------------------------------------------------- > ------------------ >=20 >=20 >> _______________________________________________ >> Rohc mailing list >> Rohc@ietf.org >> https://www1.ietf.org/mailman/listinfo/rohc >>=20 >=20 >=20 > ______________________________________________________________________ >=20 >=20 > ______________________________________________________________________ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 05 06:39:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuTSv-0007fD-5T; Thu, 05 Jan 2006 06:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuTSs-0007al-Qj for rohc@megatron.ietf.org; Thu, 05 Jan 2006 06:39:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01116 for ; Thu, 5 Jan 2006 06:38:15 -0500 (EST) From: pelle@cdt.luth.se Received: from lisa.sm.luth.se ([130.240.3.1] helo=sm.luth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuTYY-0006cX-Iu for rohc@ietf.org; Thu, 05 Jan 2006 06:45:23 -0500 Received: from localhost (localhost [127.0.0.1]) by sm.luth.se (8.12.9/8.13.0) with ESMTP id k05BdJwF025900; Thu, 5 Jan 2006 12:39:19 +0100 (MET) Received: from 84.216.77.190 ([84.216.77.190]) by www.sm.luth.se (IMP) with HTTP for ; Thu, 05 Jan 2006 12:39:19 +0100 Message-ID: <1136461159.43bd05675abff@www.sm.luth.se> Date: Thu, 05 Jan 2006 12:39:19 +0100 To: "Kristofer Sandlund (LU/EAB)" Subject: RE: [rohc] Timer-based compression References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 84.216.77.190 X-Spam-Score: 0.3 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Content-Transfer-Encoding: 8bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Quoting "Kristofer Sandlund (LU/EAB)" : > But one simple solution is to just not use it! On a sidetrack... Is Timer-based compression something that we feel is unnecessary for the updated set of profiles, or do I misunderstand your comment? I had a quick look in http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-improvements- 01.txt where I didn't find anything related to Timer-based compression. Alternatively, do we want its usage to setup in a different manner than how it currently is in 3095? /Ghyslain > /Kristofer > > > > > BR, > > Kavitha K.R., > > L&T Infotech, > > Bangalore. > > > > ( ) L&T Infotech Proprietary & Confidential > > ( ) L&T Infotech Confidential > > (+) L&T Infotech Internal Use only > > ( ) General Business Information > > > > > > > > "Lars-Erik Jonsson" > > > > 01/05/2006 02:28 PM To > > "Kavitha KR" , > > cc > > Subject > > Re: [rohc] Timer-based compression > > > > > > > > > > > > > > The decompressor can also send a CLOCK option vith value zero, but > > a compressor is still not allowed to start timer-based compression > > before it has received the CLOCK option. The specifications do not > > allow that, > > and one reason for that is the fact that the compressor can > > not know how > > to compress with timer-based compression without knowing the clock > > resolution. > > > > /L-E > > > > > > ----- Original Message ----- > > From: "Kavitha KR" > > To: > > Sent: Thursday, January 05, 2006 9:52 AM > > Subject: Re: [rohc] Timer-based compression > > > > > >> Hi L-E/Kristofer, > >> > >> But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 > >> of 3095, > >> > >> "The smallest clock resolution which can be indicated is 1 > >> millisecond. The value zero has a special meaning: it indicates that > >> the decompressor cannot do timer-based compression of the RTP > >> Timestamp." > >> > >> So even if there are impertinent Compressors (Scenario 2 and 4), > >> Decompressors can still send CLOCK value zero and > >> choose not to do timer based decompression. Isn't it so ? > >> > >> > >> Regards, > >> Kavitha K.R., > >> L&T Infotech, > >> Bangalore. > >> > >> ( ) L&T Infotech Proprietary & Confidential > >> ( ) L&T Infotech Confidential > >> (+) L&T Infotech Internal Use only > >> ( ) General Business Information > >> > >> > >> > >> "Lars-Erik Jonsson" > >> 01/05/2006 02:10 PM > >> > >> To > >> , "Kavitha KR" > >> cc > >> > >> Subject > >> Re: [rohc] Timer-based compression > >> > >> > >> > >> > >> > >> > >> Kavitha, > >> > >> As said in the implementer's guide, "Before timer-based compression > >> can be used, the decompressor will have to inform the compressor (on > >> a per- channel basis) about its clock resolution." > >> > >> This means only scenario 1 and 3 make sense. The compressor is not > >> allowed to start timer-based compression before the decompressor has > >> sent the clock resolution (i.e. the CLOCK option). > >> > >> BR > >> /L-E > >> > >> > >> ----- Original Message ----- > >> From: "Kavitha KR" > >> To: > >> Sent: Thursday, January 05, 2006 9:35 AM > >> Subject: RE: [rohc] Timer-based compression > >> > >> > >>> Hi, > >>> > >>> There could be 4 cases for switching from scaled TS compression to > >>> Timer based compression of RTP TS. > >>> > >>> Scenario 1 : Decompressor initializes and compressor accepts > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. D => send feedback with CLOCK option > >>> C => send TIME_STRIDE information (timer based compression starts > >>> here) Further packet flow continues with timer based > >>> compression.................. > >>> > >>> Scenario 2: Compressor initializes and decompressor accepts > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. C=> send TIME_STRIDE information (timer based > >>> compression starts here) D=> send feedback with CLOCK option > >>> Further packet flow continues with timer based > >>> compression.................. > >>> > >>> Scenario 3: Decompressor initializes and compressor rejects > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. D => send feedback with CLOCK option > >>> C=> No TIME_STRIDE info is sent (indicates not wanting to switch to > >>> Timer Based) Further packet flow continues with scaled timestamp > >>> compression.................. > >>> > >>> Scenario 4: Compressor initializes and decompressor rejects > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. C =>send TIME_STRIDE information > >>> D=> send feedback with CLOCK option set to zero (means no desire to > >>> do timer based compression) Further packet flow continues with > >>> scaled timestamp compression.................. > >>> > >>> For various compressor and decompressor implementations to > >>> interoperate, this may be the minimum set to be taken care. > >>> > >>> > >>> ================================================= > >>> When your work speaks for itself, get out of the way. -- Thomas > >>> 'Wayne' Brazell ================================================= > >>> Kavitha K.R., > >>> L&T Infotech, > >>> Bangalore. > >>> > >>> ( ) L&T Infotech Proprietary & Confidential > >>> ( ) L&T Infotech Confidential > >>> (+) L&T Infotech Internal Use only > >>> ( ) General Business Information > >>> > >>> > >>> > >>> "Kristofer Sandlund \(LU/EAB\)" > >>> 01/05/2006 01:26 PM > >>> > >>> To > >>> "Sarkar, Biplab" , "Kavitha KR" > >>> cc > >>> > >>> Subject > >>> RE: [rohc] Timer-based compression > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> Implementer's guide section 4.3: > >>> > >>> Before timer-based compression can be used, the decompressor will > >>> have to inform the compressor (on a per-channel basis) about its > >>> clock resolution. Further, the compressor has to send (on a per- > >>> context basis) a non-zero TIME_STRIDE to the decompressor. > >>> > >>> When the compressor is confident that the decompressor has > >>> received the TIME_STRIDE value, it can switch to timer-based > >>> compression. During this transition from window-based compression > >>> to timer-based compression, it is necessary that the compressor > >>> keep k large enough to cover both interpretation intervals. > >>> > >>> So the procedure is: > >>> 0) TIME_STRIDE starts out as zero > >>> 1) CLOCK option is sent by decompressor and received by compressor > >>> 2) Compressor decides that it wants to use timer-based compression. > >>> If so, the compressor sends a non-zero TIME_STRIDE > >>> 3) Compressor repeats time-stride until it is _confident_ that the > >>> decompressor has correctly received the new TIME_STRIDE. Note that > >>> these packet are already encoded with timer-based compression > >>> since they contain a time-stride that is non-zero. > >>> 4) All packets sent after this that contain an encoded timestamp are > >>> assumed to be using timer-based compression. > >>> > >>> The timer-based compression initialization seems to be the most > >>> frequent question on this list, but I don't know how to improve the > >>> text in the impl-guide any further. I thought it was quite clear > >>> now, but obviously it still isn't good enough. Do you have any > >>> suggestions on how to improve it further? > >>> > >>> BR, > >>> Kristofer > >>> > >>> > >>> rohc-bounces@ietf.org wrote: > >>> > >>>> Hi Kavitha, > >>>> > >>>> > >>>> > >>>> I believe with the UOR-2+ext-3 the compressor says that it > >>>> "can" support "timer-based" compression. If the decompressor > >>>> supports this, it can send an ACK with the CLOCK option. Once > >>>> the compressor gets the CLOCK-opt from the decompressor it > >>>> can change to the "timer-based" compression. But it doesn't > >>>> let the decompressor know precisely when to start expecting > >>>> packets compressed with "timer-based" compression. There has > >>>> to be some way to tell the decompressor that the current > >>>> packet is compressed with the "timer-based" compression algo. > >>>> I don't see any flags for this in the RFC. One has to > >>>> consider the number of packets on transit before deciding to > >>>> change the compression algorithm after the initial negotiation. > >>>> > >>>> > >>>> > >>>> Thanks > >>>> > >>>> Biplab > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: rohc-bounces@ietf.org > > [mailto:rohc-bounces@ietf.org] On Behalf > >>>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM > >>>> To: rohc@ietf.org > >>>> Subject: Re: [rohc] Timer-based compression > >>>> > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> Compressor can be made to send an UOR-2 packet with ext-3 or > >>>> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it > >>>> begins to do Timer based Compression of TS. It is a way to > >>>> indicate timer-based compression of TS to the decompressor. > >>>> (Refer RFC 3095 Sec 5.7.5 Extension Formats) > >>>> > >>>> Kavitha K.R., > >>>> L&T Infotech, > >>>> Bangalore. > >>>> > >>>> ( ) L&T Infotech Proprietary & Confidential > >>>> ( ) L&T Infotech Confidential > >>>> () L&T Infotech Internal Use only > >>>> (+) General Business Information > >>>> > >>>> > >>>> > >>>> "Sarkar, Biplab" > >>>> Sent by: rohc-bounces@ietf.org > >>>> > >>>> 01/05/2006 11:41 AM > >>>> > >>>> To > >>>> > >>>> > >>>> > >>>> cc > >>>> > >>>> > >>>> > >>>> Subject > >>>> > >>>> [rohc] Timer-based compression > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> All, > >>>> > >>>> I have a query. > >>>> > >>>> How does the decompressor know "from" which packet onward it > >>>> would be getting packets encoded with > >>>> timer-based-compression? Since the ACK from the decompressor > >>>> which carries the CLOCK option might take some time to reach > >>>> and get processed at the compressor; is there any way for the > >>>> decompressor to know when to expect packets to be encoded > >>>> with the timer-based compression method. > >>>> > >>>> Thanks > >>>> Biplab > >>>> > >>>> ++++++++++++++++++++++++++++++++ > >>>> Biplab Sarkar > >>>> Starent Networks, Bangalore > >>>> ++++++++++++++++++++++++++++++++ > >>>> > >>>> > >>>> > >>>> ______________________________________________________________ > >>>> _______________________________________________________ > >>>> Rohc mailing list > >>>> Rohc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/rohc > >>>> > >>>> > >>>> > > ______________________________________________________________________ > >>> > >>> > >>> > > ______________________________________________________________________ > >>> > >>> > >>> > >>> > > ______________________________________________________________________ > >> > >> > >> > > -------------------------------------------------------------- > > ------------------ > >> > >> > >>> _______________________________________________ > >>> Rohc mailing list > >>> Rohc@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/rohc > >>> > >> > >> > >> > > ______________________________________________________________________ > >> > >> > >> > >> > > ______________________________________________________________________ > > > > > > -------------------------------------------------------------- > > ------------------ > > > > > >> _______________________________________________ > >> Rohc mailing list > >> Rohc@ietf.org > >> https://www1.ietf.org/mailman/listinfo/rohc > >> > > > > > > ______________________________________________________________________ > > > > > > ______________________________________________________________________ > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 05 06:55:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuTiZ-0005mN-6O; Thu, 05 Jan 2006 06:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuTiX-0005ky-1F for rohc@megatron.ietf.org; Thu, 05 Jan 2006 06:55:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02732 for ; Thu, 5 Jan 2006 06:54:25 -0500 (EST) Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuToC-00076j-BC for rohc@ietf.org; Thu, 05 Jan 2006 07:01:33 -0500 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 8F70B37EEA; Thu, 5 Jan 2006 12:55:29 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 57EBC37E84; Thu, 5 Jan 2006 12:55:29 +0100 (CET) Received: from jymden (81-235-131-199-no14.tbcn.telia.com [81.235.131.199]) by smtp4-1-sn2.hy.skanova.net (Postfix) with SMTP id 158D737E42; Thu, 5 Jan 2006 12:55:29 +0100 (CET) Message-ID: <009201c611ef$06f84e30$6500a8c0@jymden> From: "Lars-Erik Jonsson" To: , "Kristofer Sandlund (LU/EAB)" References: <1136461159.43bd05675abff@www.sm.luth.se> Subject: Re: [rohc] Timer-based compression Date: Thu, 5 Jan 2006 12:56:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Timer-based compression has never been brought up as something undesirable, not-worth-the-effort, or as a candidate for removal. That is why it is not part of the improvements draft. Personally, I think it does not really hurt to keep it, but I do not care much about it either. Assuming we keep it, I do not see anything wrong with the way it is set up, just that it should be made clear how it works, as in the implementer's guide. Requiring the decompressing to "announce" its ability to use it and then ultimately let the compressor choose whether to use it, is in my opinion the Right Way (tm) to design the usage negotiation. Rgds, /L-E ----- Original Message ----- From: To: "Kristofer Sandlund (LU/EAB)" Cc: Sent: Thursday, January 05, 2006 12:39 PM Subject: RE: [rohc] Timer-based compression Quoting "Kristofer Sandlund (LU/EAB)" : > But one simple solution is to just not use it! On a sidetrack... Is Timer-based compression something that we feel is unnecessary for the updated set of profiles, or do I misunderstand your comment? I had a quick look in http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-improvements- 01.txt where I didn't find anything related to Timer-based compression. Alternatively, do we want its usage to setup in a different manner than how it currently is in 3095? /Ghyslain > /Kristofer > > > > > BR, > > Kavitha K.R., > > L&T Infotech, > > Bangalore. > > > > ( ) L&T Infotech Proprietary & Confidential > > ( ) L&T Infotech Confidential > > (+) L&T Infotech Internal Use only > > ( ) General Business Information > > > > > > > > "Lars-Erik Jonsson" > > > > 01/05/2006 02:28 PM To > > "Kavitha KR" , > > cc > > Subject > > Re: [rohc] Timer-based compression > > > > > > > > > > > > > > The decompressor can also send a CLOCK option vith value zero, but > > a compressor is still not allowed to start timer-based compression > > before it has received the CLOCK option. The specifications do not > > allow that, > > and one reason for that is the fact that the compressor can > > not know how > > to compress with timer-based compression without knowing the clock > > resolution. > > > > /L-E > > > > > > ----- Original Message ----- > > From: "Kavitha KR" > > To: > > Sent: Thursday, January 05, 2006 9:52 AM > > Subject: Re: [rohc] Timer-based compression > > > > > >> Hi L-E/Kristofer, > >> > >> But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 > >> of 3095, > >> > >> "The smallest clock resolution which can be indicated is 1 > >> millisecond. The value zero has a special meaning: it indicates that > >> the decompressor cannot do timer-based compression of the RTP > >> Timestamp." > >> > >> So even if there are impertinent Compressors (Scenario 2 and 4), > >> Decompressors can still send CLOCK value zero and > >> choose not to do timer based decompression. Isn't it so ? > >> > >> > >> Regards, > >> Kavitha K.R., > >> L&T Infotech, > >> Bangalore. > >> > >> ( ) L&T Infotech Proprietary & Confidential > >> ( ) L&T Infotech Confidential > >> (+) L&T Infotech Internal Use only > >> ( ) General Business Information > >> > >> > >> > >> "Lars-Erik Jonsson" > >> 01/05/2006 02:10 PM > >> > >> To > >> , "Kavitha KR" > >> cc > >> > >> Subject > >> Re: [rohc] Timer-based compression > >> > >> > >> > >> > >> > >> > >> Kavitha, > >> > >> As said in the implementer's guide, "Before timer-based compression > >> can be used, the decompressor will have to inform the compressor (on > >> a per- channel basis) about its clock resolution." > >> > >> This means only scenario 1 and 3 make sense. The compressor is not > >> allowed to start timer-based compression before the decompressor has > >> sent the clock resolution (i.e. the CLOCK option). > >> > >> BR > >> /L-E > >> > >> > >> ----- Original Message ----- > >> From: "Kavitha KR" > >> To: > >> Sent: Thursday, January 05, 2006 9:35 AM > >> Subject: RE: [rohc] Timer-based compression > >> > >> > >>> Hi, > >>> > >>> There could be 4 cases for switching from scaled TS compression to > >>> Timer based compression of RTP TS. > >>> > >>> Scenario 1 : Decompressor initializes and compressor accepts > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. D => send feedback with CLOCK option > >>> C => send TIME_STRIDE information (timer based compression starts > >>> here) Further packet flow continues with timer based > >>> compression.................. > >>> > >>> Scenario 2: Compressor initializes and decompressor accepts > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. C=> send TIME_STRIDE information (timer based > >>> compression starts here) D=> send feedback with CLOCK option > >>> Further packet flow continues with timer based > >>> compression.................. > >>> > >>> Scenario 3: Decompressor initializes and compressor rejects > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. D => send feedback with CLOCK option > >>> C=> No TIME_STRIDE info is sent (indicates not wanting to switch to > >>> Timer Based) Further packet flow continues with scaled timestamp > >>> compression.................. > >>> > >>> Scenario 4: Compressor initializes and decompressor rejects > >>> ===================================================== > >>> Packet flow with scaled timestamp compression going > >>> on................. C =>send TIME_STRIDE information > >>> D=> send feedback with CLOCK option set to zero (means no desire to > >>> do timer based compression) Further packet flow continues with > >>> scaled timestamp compression.................. > >>> > >>> For various compressor and decompressor implementations to > >>> interoperate, this may be the minimum set to be taken care. > >>> > >>> > >>> ================================================= > >>> When your work speaks for itself, get out of the way. -- Thomas > >>> 'Wayne' Brazell ================================================= > >>> Kavitha K.R., > >>> L&T Infotech, > >>> Bangalore. > >>> > >>> ( ) L&T Infotech Proprietary & Confidential > >>> ( ) L&T Infotech Confidential > >>> (+) L&T Infotech Internal Use only > >>> ( ) General Business Information > >>> > >>> > >>> > >>> "Kristofer Sandlund \(LU/EAB\)" > >>> 01/05/2006 01:26 PM > >>> > >>> To > >>> "Sarkar, Biplab" , "Kavitha KR" > >>> cc > >>> > >>> Subject > >>> RE: [rohc] Timer-based compression > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> Implementer's guide section 4.3: > >>> > >>> Before timer-based compression can be used, the decompressor will > >>> have to inform the compressor (on a per-channel basis) about its > >>> clock resolution. Further, the compressor has to send (on a per- > >>> context basis) a non-zero TIME_STRIDE to the decompressor. > >>> > >>> When the compressor is confident that the decompressor has > >>> received the TIME_STRIDE value, it can switch to timer-based > >>> compression. During this transition from window-based compression > >>> to timer-based compression, it is necessary that the compressor > >>> keep k large enough to cover both interpretation intervals. > >>> > >>> So the procedure is: > >>> 0) TIME_STRIDE starts out as zero > >>> 1) CLOCK option is sent by decompressor and received by compressor > >>> 2) Compressor decides that it wants to use timer-based compression. > >>> If so, the compressor sends a non-zero TIME_STRIDE > >>> 3) Compressor repeats time-stride until it is _confident_ that the > >>> decompressor has correctly received the new TIME_STRIDE. Note that > >>> these packet are already encoded with timer-based compression > >>> since they contain a time-stride that is non-zero. > >>> 4) All packets sent after this that contain an encoded timestamp are > >>> assumed to be using timer-based compression. > >>> > >>> The timer-based compression initialization seems to be the most > >>> frequent question on this list, but I don't know how to improve the > >>> text in the impl-guide any further. I thought it was quite clear > >>> now, but obviously it still isn't good enough. Do you have any > >>> suggestions on how to improve it further? > >>> > >>> BR, > >>> Kristofer > >>> > >>> > >>> rohc-bounces@ietf.org wrote: > >>> > >>>> Hi Kavitha, > >>>> > >>>> > >>>> > >>>> I believe with the UOR-2+ext-3 the compressor says that it > >>>> "can" support "timer-based" compression. If the decompressor > >>>> supports this, it can send an ACK with the CLOCK option. Once > >>>> the compressor gets the CLOCK-opt from the decompressor it > >>>> can change to the "timer-based" compression. But it doesn't > >>>> let the decompressor know precisely when to start expecting > >>>> packets compressed with "timer-based" compression. There has > >>>> to be some way to tell the decompressor that the current > >>>> packet is compressed with the "timer-based" compression algo. > >>>> I don't see any flags for this in the RFC. One has to > >>>> consider the number of packets on transit before deciding to > >>>> change the compression algorithm after the initial negotiation. > >>>> > >>>> > >>>> > >>>> Thanks > >>>> > >>>> Biplab > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: rohc-bounces@ietf.org > > [mailto:rohc-bounces@ietf.org] On Behalf > >>>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM > >>>> To: rohc@ietf.org > >>>> Subject: Re: [rohc] Timer-based compression > >>>> > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> Compressor can be made to send an UOR-2 packet with ext-3 or > >>>> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it > >>>> begins to do Timer based Compression of TS. It is a way to > >>>> indicate timer-based compression of TS to the decompressor. > >>>> (Refer RFC 3095 Sec 5.7.5 Extension Formats) > >>>> > >>>> Kavitha K.R., > >>>> L&T Infotech, > >>>> Bangalore. > >>>> > >>>> ( ) L&T Infotech Proprietary & Confidential > >>>> ( ) L&T Infotech Confidential > >>>> () L&T Infotech Internal Use only > >>>> (+) General Business Information > >>>> > >>>> > >>>> > >>>> "Sarkar, Biplab" > >>>> Sent by: rohc-bounces@ietf.org > >>>> > >>>> 01/05/2006 11:41 AM > >>>> > >>>> To > >>>> > >>>> > >>>> > >>>> cc > >>>> > >>>> > >>>> > >>>> Subject > >>>> > >>>> [rohc] Timer-based compression > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> All, > >>>> > >>>> I have a query. > >>>> > >>>> How does the decompressor know "from" which packet onward it > >>>> would be getting packets encoded with > >>>> timer-based-compression? Since the ACK from the decompressor > >>>> which carries the CLOCK option might take some time to reach > >>>> and get processed at the compressor; is there any way for the > >>>> decompressor to know when to expect packets to be encoded > >>>> with the timer-based compression method. > >>>> > >>>> Thanks > >>>> Biplab > >>>> > >>>> ++++++++++++++++++++++++++++++++ > >>>> Biplab Sarkar > >>>> Starent Networks, Bangalore > >>>> ++++++++++++++++++++++++++++++++ > >>>> > >>>> > >>>> > >>>> ______________________________________________________________ > >>>> _______________________________________________________ > >>>> Rohc mailing list > >>>> Rohc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/rohc > >>>> > >>>> > >>>> > > ______________________________________________________________________ > >>> > >>> > >>> > > ______________________________________________________________________ > >>> > >>> > >>> > >>> > > ______________________________________________________________________ > >> > >> > >> > > -------------------------------------------------------------- > > ------------------ > >> > >> > >>> _______________________________________________ > >>> Rohc mailing list > >>> Rohc@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/rohc > >>> > >> > >> > >> > > ______________________________________________________________________ > >> > >> > >> > >> > > ______________________________________________________________________ > > > > > > -------------------------------------------------------------- > > ------------------ > > > > > >> _______________________________________________ > >> Rohc mailing list > >> Rohc@ietf.org > >> https://www1.ietf.org/mailman/listinfo/rohc > >> > > > > > > ______________________________________________________________________ > > > > > > ______________________________________________________________________ > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Jan 09 18:16:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6Fk-00087M-Ro; Mon, 09 Jan 2006 18:16:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6Fj-000873-MG for rohc@megatron.ietf.org; Mon, 09 Jan 2006 18:16:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06929 for ; Mon, 9 Jan 2006 18:15:18 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6MG-0001I1-3n for rohc@ietf.org; Mon, 09 Jan 2006 18:23:26 -0500 Received: by xproxy.gmail.com with SMTP id t12so1394680wxc for ; Mon, 09 Jan 2006 15:16:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fwtM34uYhLoccwnT6QAma/3e4j20Wv/akn2hTEPstjlSF9CgtYWEn8dT48GzX4x1fkBJv1b0HBGbr4xb+Jqwt3UqhaMvwVjsjx7P9EWnnWNc4oHL9qe81BjVikzudGtNZV91kLXokInmfTH61Mku/KtHKw8keIRZi7cOZo/Y+tQ= Received: by 10.70.10.7 with SMTP id 7mr5721476wxj; Mon, 09 Jan 2006 15:16:34 -0800 (PST) Received: by 10.70.80.12 with HTTP; Mon, 9 Jan 2006 15:16:34 -0800 (PST) Message-ID: Date: Mon, 9 Jan 2006 18:16:34 -0500 From: Qinqing Zhang To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Subject: [rohc] ROHC parameter configurations at the radio access network. X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Dear ROHC experts: In a recent 3GPP2 standard document, TIA-1054 (not the final version), there is a proposal to add two attributes related with ROHC parameters configurated at the air interface. The two attributes are TimerBasedCompression, and DelayCompressionDepth. The description of=20 these two attributes are as follows: DelayCompressionDepth: The sender shall set this field to the maximum number of packets that can be buffered and thus possibly be delayed decompressed by the decompressor according to ROHC RFC3095 for this ROHC channel. If the value of this field is 0, then delayed compression shall not be enabled. The sender shall not set this field to a value greater than MaxSupportedDelayedDecompressionDepth. TimerBasedCompression: The sender shall set this field to "0" if timer based compression is not enabled for this ROHC channel. The sender shall set this field to "1" if timer based compression is enabled for this ROHC channel. If TimerBasedCompressionSupported is set to "0", then the sender shall not set this field to "1". I do not quite see the needs for adding these two attributes at the air interface standards. These two parameters are purely ROHC implementation parameters, which should be handled by the compressor and decompressor, not by RAN, a 3rd party. The arguments I heard about is that the RAN can make sure that the access terminal will use the timerbased compression for the voice application. and will not use timer based compression for the video application, by setting the TimerBasedCompression attribute for each flow. Does this make sense? Another question is that for this delayed compression, is there any implementation issue that this option is actually not recommended? I do not intend to bring the discussion from 3GPP2 standards to the IETF standards. But since this is related with ROHC, I would like to seek the opinion from the IETF ROHC experts. Thanks in advance for your kind reply. Regards, Qinqing _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Jan 10 04:49:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwG7i-0003hq-HM; Tue, 10 Jan 2006 04:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwG7h-0003hl-53 for rohc@megatron.ietf.org; Tue, 10 Jan 2006 04:49:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18298 for ; Tue, 10 Jan 2006 04:47:41 -0500 (EST) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwGEL-0003FZ-N8 for rohc@ietf.org; Tue, 10 Jan 2006 04:55:55 -0500 Received: from [192.168.101.51] (c-c67c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.198]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id k0A8w8cF032460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Jan 2006 09:58:09 +0100 Message-ID: <43C382F5.4080604@effnet.com> Date: Tue, 10 Jan 2006 10:48:37 +0100 From: Carl Knutsson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org, "Lars-Erik Jonsson (LU/EAB)" X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Subject: [rohc] WGLC Reveiw RFC3095 Implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Lars-Erik, all, Over all, I am pretty pleased with ROHC Implementer's guide. I have some comments... When referring to a section to another document, you have to specify the document, not just the section. It is not clear if it refers to this document (Implementer's guide) or the rfc3095. Maybe this is common practice for updating rfcs. Section 8.10: It could be worth to mention that this section applies to profile 3 (ESP) too. rfc3095 section 5.12.2 specifies that profile 3 uses the same packet formats as profile 2. It wouldn't hurt to write it one more time. Section 8.13: " Sequence Number: Not sent when the offset from the sequence number of the compressed header is constant. When the offset is not constant, the sequence number is compressed by sending LSBs. See 5.8.4." The reference to section 5.8.4 is a bit confusing. At least until I realized that the text is copied from rfc3095. Please include a reference to rfc3095 in this section. Quotation marks are used in earlier sections, it could be used here too. In section 6.2 and 8.3, I believe it should be explained that the context is updated with index-item pairs for UO-1-ID with extension3. It could be added as a reference to section 5.4. Regards, Carl Knutsson Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Jan 10 10:00:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKzC-0001HY-PB; Tue, 10 Jan 2006 10:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKzB-0001HT-H5 for rohc@megatron.ietf.org; Tue, 10 Jan 2006 10:00:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08517 for ; Tue, 10 Jan 2006 09:59:14 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwL5n-0003oT-QU for rohc@ietf.org; Tue, 10 Jan 2006 10:07:30 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C4BA54F0002; Tue, 10 Jan 2006 16:00:12 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 16:00:12 +0100 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 16:00:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC parameter configurations at the radio access network. Date: Tue, 10 Jan 2006 16:00:11 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0501CD551C@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] ROHC parameter configurations at the radio access network. Thread-Index: AcYVcwucoqgSnHmwT+eskjClVqOagAAcWU+Q From: "Ghyslain Pelletier \(LU/EAB\)" To: "Qinqing Zhang" , X-OriginalArrivalTime: 10 Jan 2006 15:00:12.0597 (UTC) FILETIME=[8EA53E50:01C615F6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Qinqing, I had a quick look at C.P0063-0_v1.15 (i.e. the V&V version), section 2.9.2.5.1. (I assume in this section "supported" means "used for this RoHC channel"?) Comments inline. > I do not quite see the needs for adding these two attributes > at the air interface standards. These two parameters are > purely ROHC implementation parameters, which should be > handled by the compressor and decompressor, not by RAN, a 3rd > party. I completely agree with you on this. > The arguments I heard about is that the RAN can make > sure that the access terminal will use the timerbased > compression for the voice application, and will not use timer > based compression for the video application, by setting the > TimerBasedCompression attribute for each flow. These seem to be somewhat rather weak arguments. First, from IETF specs (3095 + implementer's guide) neither the compressor or the decompressor are mandated to implement and support timer-based TS compression. Second, for video, the compressor would not use it anyway because of the change pattern of the TS that would hinder the use of timer-based compression. Thirdly, for voice, the gain of timer-based compression is very small (closer to insignificant IMHO). More specifically, from the way 3095 is written and together with the clarifications from the implementer's guide (section section 4.3), it is the decompressor that decides if Timer-based compression MAY be used or not by the compressor. The decompressor can signal this that it supports timer-based decompression by sending a feedback with a CLOCK option. This is then valid for any flow over that RoHC channel. In this respect, the decompressor is never mandated to implement Timer-based compression. The compressor MAY then (but is not mandated to), on a per-context basis, choose to use timer-based compression or not - for this the compressor has to send a non-zero TIME_STRIDE to the decompressor. In this respect, the compressor is never mandated to implement Timer-based compression either. See also a fine mail by Kristofer S. on this: http://www.ietf.org/mail-archive/web/rohc/current/msg04097.html With respect to the gain of this encoding method, it is mainly only applicable to audio flows. Its gain is localized to right after the end of a DTX period, at the beginning of the new talkspurt. At this point, timer-based compression allows the compressor to send a UOR-2 header without any extension, while without timer-based compression it would normally have had to send at least a one-byte extension (e.g. extension type 0). The total gain is thus at most 1 byte for a number k of compressed packets, where k corresponds to the number of packets sent in UO-mode for the optimistic approach (i.e. normally equal to the maximum number of consecutive losses over the link). We normally fix the value of k to around k =3D 3, so the total gain becomes ... 3 octets per talkspurt = when compared to not using it. > Does this make sense? I am not sure that the suggested parameter is really useful. First, this mandates that ROHC implementations willing to be compliant to 3GPP2 specs shall support timer-based compression, which is currently not mandated by IETF specifications as explained above, for neither compressor or decompressor. Second, the gain of timer-based compression is very limited, even insignificant with respect to the added complexity of supporting it IMHO. So, would 3GPP2 really feels that these few octets are worth the fight, then it should at least mandate RoHC implementations to explicitely support Timer-based compression. But this is not something that I would recommend to do anyway. > Another question is that for this delayed compression, is > there any implementation issue that this option is actually not > recommended?=20 I assume that delayed compression refers to the reverse compression of 3095, section 6.1. I am not sure what potential implementation issue you are referring to, but reverse decompression is definitely purely an implementation feature for the decompressor and IMHO it should not be mandated to support. Secondly, I wonder what is the purpose of having a parameter for specifying reverse decompression? Is it meant as a "hint" for the decompressor? If so, is it a hint for the purpose of indicating some kind of maximum delay requirement? Otherwise, what prevents a decompressor to ignore this parameter altogether and not perform reverse decompression at all? Finally, it seems to me that it is rather likely that the actual depth for being successful with this "feature" would exceed the delay requirements of the real-time flow(s). This is because the decompressor must store all packets that have not successfully been decompressed until a UOR-2, IR, or IR-DYN that solves the problem is received, and these are normally infrequently sent by the compressor - mainly only when feedback is received for a context repair. In other words, I normally don't recommend the use of reverse decompression at any time. So, in short, I would suggest that these two parameters not be included in C.P0063-0, but on the other end I do not believe that they will hurt anything other than mandating the use of timer-based compression for all implementers. MaxSupportedDelayedDecompressionDepth will have in my opinion no effect. I hope this helps you somewhat, Regards, /Ghyslain rohc-bounces@ietf.org wrote: > Dear ROHC experts: >=20 > In a recent 3GPP2 standard document, TIA-1054 (not the final > version), there is a proposal to add two attributes related > with ROHC parameters configurated at the air interface. The > two attributes are TimerBasedCompression, and > DelayCompressionDepth. The description of these two attributes are as > follows:=20 >=20 > DelayCompressionDepth: > The sender shall set this field to the maximum number of > packets that can be buffered and thus possibly be delayed > decompressed by the decompressor according to ROHC RFC3095 > for this ROHC channel. If the value of this field is 0, then > delayed compression shall not be enabled. The sender shall > not set this field to a value greater than > MaxSupportedDelayedDecompressionDepth. >=20 > TimerBasedCompression: > The sender shall set this field to "0" if timer based > compression is not enabled for this ROHC channel. The sender > shall set this field to "1" if timer based compression is > enabled for this ROHC channel. If > TimerBasedCompressionSupported is set to "0", then the sender > shall not set this field to "1". >=20 > I do not quite see the needs for adding these two attributes > at the air interface standards. These two parameters are > purely ROHC implementation parameters, which should be > handled by the compressor and decompressor, not by RAN, a 3rd > party. The arguments I heard about is that the RAN can make > sure that the access terminal will use the timerbased > compression for the voice application. and will not use timer > based compression for the video application, by setting the > TimerBasedCompression attribute for each flow. > Does this make sense? > Another question is that for this delayed compression, is > there any implementation issue that this option is actually not > recommended?=20 >=20 > I do not intend to bring the discussion from 3GPP2 standards > to the IETF standards. But since this is related with ROHC, I > would like to seek the opinion from the IETF ROHC experts. >=20 > Thanks in advance for your kind reply. >=20 > Regards, > Qinqing >=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 rohc-bounces@ietf.org Tue Jan 10 11:26:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMJz-0005BB-2g; Tue, 10 Jan 2006 11:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMJy-0005B5-1H for rohc@megatron.ietf.org; Tue, 10 Jan 2006 11:26:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18483 for ; Tue, 10 Jan 2006 11:24:46 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMQh-00080k-Iz for rohc@ietf.org; Tue, 10 Jan 2006 11:33:04 -0500 Received: by xproxy.gmail.com with SMTP id t12so1503159wxc for ; Tue, 10 Jan 2006 08:26:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=siJ7PWXspqaMMo3JyYjW63z+gZePcdtGg16yV5EhZ8anDzbUApDZv+w0xEDAEaWWxiHXdU5txfUqsGAeq7pFa4RJ50B4TDZBUdWJJD2NdZkcNvGNqddRe6Mr385oPshhirMrwdOnDJsb8+JzzbrHyVPemIMQHlRbCd6m64Z4Dq4= Received: by 10.70.30.19 with SMTP id d19mr6869154wxd; Tue, 10 Jan 2006 08:26:04 -0800 (PST) Received: by 10.70.80.12 with HTTP; Tue, 10 Jan 2006 08:26:04 -0800 (PST) Message-ID: Date: Tue, 10 Jan 2006 11:26:04 -0500 From: Qinqing Zhang To: "Ghyslain Pelletier (LU/EAB)" In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0501CD551C@esealmw109.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <026F8EEDAD2C4342A993203088C1FC0501CD551C@esealmw109.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org Subject: [rohc] Re: ROHC parameter configurations at the radio access network. X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Ghyslain: Thank you for your thorough comments and suggestion. I completely agree with your arguments on why these two attributes should not be included in the 3GPP2 RAN standards. Another note is that for some voice flows over the RAN, silence suppression may not be supported. If there is no silence suppression (or 1/8 rate blanking), TS does not need to be compressed. It will be deferred from the SN. Timer based compression has no merits in this scenario. In the ROHC improvement draft, draft-ietf-rohc-rfc3095bis-improvements-01.txt, section 6.1 on reverse decompression, it is suggested to remove the reverse decompression described in RFC3095, section 6.1, since it is "a very questionable implementation". I would assume that the DelayCompressionDepth has no merits as well=20 in terms of decompression improvement. Thanks, Qinqing On 1/10/06, Ghyslain Pelletier (LU/EAB) w= rote: > Qinqing, > > I had a quick look at C.P0063-0_v1.15 (i.e. the V&V version), section > 2.9.2.5.1. > (I assume in this section "supported" means "used for this RoHC > channel"?) > > Comments inline. > > > I do not quite see the needs for adding these two attributes > > at the air interface standards. These two parameters are > > purely ROHC implementation parameters, which should be > > handled by the compressor and decompressor, not by RAN, a 3rd > > party. > > I completely agree with you on this. > > > The arguments I heard about is that the RAN can make > > sure that the access terminal will use the timerbased > > compression for the voice application, and will not use timer > > based compression for the video application, by setting the > > TimerBasedCompression attribute for each flow. > > These seem to be somewhat rather weak arguments. > > First, from IETF specs (3095 + implementer's guide) neither the > compressor or the decompressor are mandated to implement and support > timer-based TS compression. Second, for video, the compressor would not > use it anyway because of the change pattern of the TS that would hinder > the use of timer-based compression. Thirdly, for voice, the gain of > timer-based compression is very small (closer to insignificant IMHO). > > More specifically, from the way 3095 is written and together with the > clarifications from the implementer's guide (section section 4.3), it is > the decompressor that decides if Timer-based compression MAY be used or > not by the compressor. The decompressor can signal this that it supports > timer-based decompression by sending a feedback with a CLOCK option. > This is then valid for any flow over that RoHC channel. In this respect, > the decompressor is never mandated to implement Timer-based compression. > The compressor MAY then (but is not mandated to), on a per-context > basis, choose to use timer-based compression or not - for this the > compressor has to send a non-zero TIME_STRIDE to the decompressor. In > this respect, the compressor is never mandated to implement Timer-based > compression either. > > See also a fine mail by Kristofer S. on this: > http://www.ietf.org/mail-archive/web/rohc/current/msg04097.html > > With respect to the gain of this encoding method, it is mainly only > applicable to audio flows. Its gain is localized to right after the end > of a DTX period, at the beginning of the new talkspurt. At this point, > timer-based compression allows the compressor to send a UOR-2 header > without any extension, while without timer-based compression it would > normally have had to send at least a one-byte extension (e.g. extension > type 0). > > The total gain is thus at most 1 byte for a number k of compressed > packets, where k corresponds to the number of packets sent in UO-mode > for the optimistic approach (i.e. normally equal to the maximum number > of consecutive losses over the link). We normally fix the value of k to > around k =3D 3, so the total gain becomes ... 3 octets per talkspurt when > compared to not using it. > > > Does this make sense? > > I am not sure that the suggested parameter is really useful. > > First, this mandates that ROHC implementations willing to be compliant > to 3GPP2 specs shall support timer-based compression, which is currently > not mandated by IETF specifications as explained above, for neither > compressor or decompressor. > > Second, the gain of timer-based compression is very limited, even > insignificant with respect to the added complexity of supporting it > IMHO. > > So, would 3GPP2 really feels that these few octets are worth the fight, > then it should at least mandate RoHC implementations to explicitely > support Timer-based compression. But this is not something that I would > recommend to do anyway. > > > Another question is that for this delayed compression, is > > there any implementation issue that this option is actually not > > recommended? > > I assume that delayed compression refers to the reverse compression of > 3095, section 6.1. I am not sure what potential implementation issue you > are referring to, but reverse decompression is definitely purely an > implementation feature for the decompressor and IMHO it should not be > mandated to support. > > Secondly, I wonder what is the purpose of having a parameter for > specifying reverse decompression? Is it meant as a "hint" for the > decompressor? If so, is it a hint for the purpose of indicating some > kind of maximum delay requirement? Otherwise, what prevents a > decompressor to ignore this parameter altogether and not perform reverse > decompression at all? > > Finally, it seems to me that it is rather likely that the actual depth > for being successful with this "feature" would exceed the delay > requirements of the real-time flow(s). This is because the decompressor > must store all packets that have not successfully been decompressed > until a UOR-2, IR, or IR-DYN that solves the problem is received, and > these are normally infrequently sent by the compressor - mainly only > when feedback is received for a context repair. > > In other words, I normally don't recommend the use of reverse > decompression at any time. > > So, in short, I would suggest that these two parameters not be included > in C.P0063-0, but on the other end I do not believe that they will hurt > anything other than mandating the use of timer-based compression for all > implementers. MaxSupportedDelayedDecompressionDepth will have in my > opinion no effect. > > I hope this helps you somewhat, > > Regards, > > /Ghyslain > > rohc-bounces@ietf.org wrote: > > Dear ROHC experts: > > > > In a recent 3GPP2 standard document, TIA-1054 (not the final > > version), there is a proposal to add two attributes related > > with ROHC parameters configurated at the air interface. The > > two attributes are TimerBasedCompression, and > > DelayCompressionDepth. The description of these two attributes are as > > follows: > > > > DelayCompressionDepth: > > The sender shall set this field to the maximum number of > > packets that can be buffered and thus possibly be delayed > > decompressed by the decompressor according to ROHC RFC3095 > > for this ROHC channel. If the value of this field is 0, then > > delayed compression shall not be enabled. The sender shall > > not set this field to a value greater than > > MaxSupportedDelayedDecompressionDepth. > > > > TimerBasedCompression: > > The sender shall set this field to "0" if timer based > > compression is not enabled for this ROHC channel. The sender > > shall set this field to "1" if timer based compression is > > enabled for this ROHC channel. If > > TimerBasedCompressionSupported is set to "0", then the sender > > shall not set this field to "1". > > > > I do not quite see the needs for adding these two attributes > > at the air interface standards. These two parameters are > > purely ROHC implementation parameters, which should be > > handled by the compressor and decompressor, not by RAN, a 3rd > > party. The arguments I heard about is that the RAN can make > > sure that the access terminal will use the timerbased > > compression for the voice application. and will not use timer > > based compression for the video application, by setting the > > TimerBasedCompression attribute for each flow. > > Does this make sense? > > Another question is that for this delayed compression, is > > there any implementation issue that this option is actually not > > recommended? > > > > I do not intend to bring the discussion from 3GPP2 standards > > to the IETF standards. But since this is related with ROHC, I > > would like to seek the opinion from the IETF ROHC experts. > > > > Thanks in advance for your kind reply. > > > > Regards, > > Qinqing > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Jan 10 12:10:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwN1F-00021h-PE; Tue, 10 Jan 2006 12:10:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwN1C-00020X-68 for rohc@megatron.ietf.org; Tue, 10 Jan 2006 12:10:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21908 for ; Tue, 10 Jan 2006 12:09:26 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwN7s-00011r-TB for rohc@ietf.org; Tue, 10 Jan 2006 12:17:44 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0AHAMoS010550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Jan 2006 09:10:23 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0AH9mFV023204; Tue, 10 Jan 2006 09:10:21 -0800 (PST) Received: from NAEX09.na.qualcomm.com ([10.46.56.82]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 09:09:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC parameter configurations at the radio access network. Date: Tue, 10 Jan 2006 09:09:32 -0800 Message-ID: Thread-Topic: [rohc] ROHC parameter configurations at the radio access network. Thread-Index: AcYVcwucoqgSnHmwT+eskjClVqOagAAcWU+QAAgNPCA= From: "Kapoor, Rohit" To: "Ghyslain Pelletier \(LU/EAB\)" , X-OriginalArrivalTime: 10 Jan 2006 17:09:35.0149 (UTC) FILETIME=[A17CADD0:01C61608] X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Ghyslain, Thanks for your comments. But, the earlier mail from Qinqing did not completely explain the procedure in 3GPP2 and let me explain it. Essentially, when the AT acquires the "network" (this is prior to setting up any flows), it sends the RAN its set of capabilities. These include whether the RoHC at the AT can do timer-based compression, delayed decompression etc. Once the RAN has this knowledge, it may ask the AT to enable timer-based compression **only if** the AT has indicated that it supports it. Else, the RAN will not ask the AT to do timer-based for any flow. Also, the RAN will typically only enable timer-based for VoIP flows and not for any other flows. Moreover, when the RAN asks the AT to enable timer-based, it only means that the AT's compressor should be ready to do timer-based (subject of course, to the decompressor sending a FEEDBACK with the CLOCK option non-zero). Similar arguments are also for reverse decompression. Again, the RAN will only ask the AT to do reverse decompression for flows which don't have strict delay requirements. If it is felt by 3GPP2 that gains are not being seen for any flow, then the RAN can always set this to 0 for all flows. One more point is that the architecture of 3GPP2 is such that the AT is supposed to be "dumb", meaning that the AT does not have knowledge of what the flow is. Of course, the AT's compressor can be smart and try to identify that the flow is doing Silence Suppression by looking at the RTP stream, but we have seen cases of implementations where the compressor is not doing this (or is getting confused while doing this) and thus, we cannot rely on the AT's compressor to identify this. The RAN, on the other hand, knows exactly what flow it is, based on some QoS Profile IDs that are exchanged prior to setting up the flow. So, the RAN is in the best situation to let the AT know. Also, even though timer-based buys only 1 or 2 bytes typically (and that too at the beginning of a talkspurt), but this 1 or 2 bytes becomes very important for us due to the fact that physical layer payloads are discrete. Meaning that sometimes even 1 extra byte causes the higher payload to be picked (which is then mostly padded away), causing a significant waste in capacity. Let me also stress here that we have been active on this list and have been following all RoHC guidelines when designing how to use RoHC in 3GPP2. Hope this helps answer your concerns. Thanks, Rohit > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf Of > Ghyslain Pelletier (LU/EAB) > Sent: Tuesday, January 10, 2006 7:00 AM > To: Qinqing Zhang; rohc@ietf.org > Subject: RE: [rohc] ROHC parameter configurations at the radio access > network. >=20 > Qinqing, >=20 > I had a quick look at C.P0063-0_v1.15 (i.e. the V&V version), section > 2.9.2.5.1. > (I assume in this section "supported" means "used for this RoHC > channel"?) >=20 > Comments inline. >=20 > > I do not quite see the needs for adding these two attributes > > at the air interface standards. These two parameters are > > purely ROHC implementation parameters, which should be > > handled by the compressor and decompressor, not by RAN, a 3rd > > party. >=20 > I completely agree with you on this. >=20 > > The arguments I heard about is that the RAN can make > > sure that the access terminal will use the timerbased > > compression for the voice application, and will not use timer > > based compression for the video application, by setting the > > TimerBasedCompression attribute for each flow. >=20 > These seem to be somewhat rather weak arguments. >=20 > First, from IETF specs (3095 + implementer's guide) neither the > compressor or the decompressor are mandated to implement and support > timer-based TS compression. Second, for video, the compressor would not > use it anyway because of the change pattern of the TS that would hinder > the use of timer-based compression. Thirdly, for voice, the gain of > timer-based compression is very small (closer to insignificant IMHO). >=20 > More specifically, from the way 3095 is written and together with the > clarifications from the implementer's guide (section section 4.3), it is > the decompressor that decides if Timer-based compression MAY be used or > not by the compressor. The decompressor can signal this that it supports > timer-based decompression by sending a feedback with a CLOCK option. > This is then valid for any flow over that RoHC channel. In this respect, > the decompressor is never mandated to implement Timer-based compression. > The compressor MAY then (but is not mandated to), on a per-context > basis, choose to use timer-based compression or not - for this the > compressor has to send a non-zero TIME_STRIDE to the decompressor. In > this respect, the compressor is never mandated to implement Timer-based > compression either. >=20 > See also a fine mail by Kristofer S. on this: > http://www.ietf.org/mail-archive/web/rohc/current/msg04097.html >=20 > With respect to the gain of this encoding method, it is mainly only > applicable to audio flows. Its gain is localized to right after the end > of a DTX period, at the beginning of the new talkspurt. At this point, > timer-based compression allows the compressor to send a UOR-2 header > without any extension, while without timer-based compression it would > normally have had to send at least a one-byte extension (e.g. extension > type 0). >=20 > The total gain is thus at most 1 byte for a number k of compressed > packets, where k corresponds to the number of packets sent in UO-mode > for the optimistic approach (i.e. normally equal to the maximum number > of consecutive losses over the link). We normally fix the value of k to > around k =3D 3, so the total gain becomes ... 3 octets per talkspurt when > compared to not using it. >=20 > > Does this make sense? >=20 > I am not sure that the suggested parameter is really useful. >=20 > First, this mandates that ROHC implementations willing to be compliant > to 3GPP2 specs shall support timer-based compression, which is currently > not mandated by IETF specifications as explained above, for neither > compressor or decompressor. >=20 > Second, the gain of timer-based compression is very limited, even > insignificant with respect to the added complexity of supporting it > IMHO. >=20 > So, would 3GPP2 really feels that these few octets are worth the fight, > then it should at least mandate RoHC implementations to explicitely > support Timer-based compression. But this is not something that I would > recommend to do anyway. >=20 > > Another question is that for this delayed compression, is > > there any implementation issue that this option is actually not > > recommended? >=20 > I assume that delayed compression refers to the reverse compression of > 3095, section 6.1. I am not sure what potential implementation issue you > are referring to, but reverse decompression is definitely purely an > implementation feature for the decompressor and IMHO it should not be > mandated to support. >=20 > Secondly, I wonder what is the purpose of having a parameter for > specifying reverse decompression? Is it meant as a "hint" for the > decompressor? If so, is it a hint for the purpose of indicating some > kind of maximum delay requirement? Otherwise, what prevents a > decompressor to ignore this parameter altogether and not perform reverse > decompression at all? >=20 > Finally, it seems to me that it is rather likely that the actual depth > for being successful with this "feature" would exceed the delay > requirements of the real-time flow(s). This is because the decompressor > must store all packets that have not successfully been decompressed > until a UOR-2, IR, or IR-DYN that solves the problem is received, and > these are normally infrequently sent by the compressor - mainly only > when feedback is received for a context repair. >=20 > In other words, I normally don't recommend the use of reverse > decompression at any time. >=20 > So, in short, I would suggest that these two parameters not be included > in C.P0063-0, but on the other end I do not believe that they will hurt > anything other than mandating the use of timer-based compression for all > implementers. MaxSupportedDelayedDecompressionDepth will have in my > opinion no effect. >=20 > I hope this helps you somewhat, >=20 > Regards, >=20 > /Ghyslain >=20 > rohc-bounces@ietf.org wrote: > > Dear ROHC experts: > > > > In a recent 3GPP2 standard document, TIA-1054 (not the final > > version), there is a proposal to add two attributes related > > with ROHC parameters configurated at the air interface. The > > two attributes are TimerBasedCompression, and > > DelayCompressionDepth. The description of these two attributes are as > > follows: > > > > DelayCompressionDepth: > > The sender shall set this field to the maximum number of > > packets that can be buffered and thus possibly be delayed > > decompressed by the decompressor according to ROHC RFC3095 > > for this ROHC channel. If the value of this field is 0, then > > delayed compression shall not be enabled. The sender shall > > not set this field to a value greater than > > MaxSupportedDelayedDecompressionDepth. > > > > TimerBasedCompression: > > The sender shall set this field to "0" if timer based > > compression is not enabled for this ROHC channel. The sender > > shall set this field to "1" if timer based compression is > > enabled for this ROHC channel. If > > TimerBasedCompressionSupported is set to "0", then the sender > > shall not set this field to "1". > > > > I do not quite see the needs for adding these two attributes > > at the air interface standards. These two parameters are > > purely ROHC implementation parameters, which should be > > handled by the compressor and decompressor, not by RAN, a 3rd > > party. The arguments I heard about is that the RAN can make > > sure that the access terminal will use the timerbased > > compression for the voice application. and will not use timer > > based compression for the video application, by setting the > > TimerBasedCompression attribute for each flow. > > Does this make sense? > > Another question is that for this delayed compression, is > > there any implementation issue that this option is actually not > > recommended? > > > > I do not intend to bring the discussion from 3GPP2 standards > > to the IETF standards. But since this is related with ROHC, I > > would like to seek the opinion from the IETF ROHC experts. > > > > Thanks in advance for your kind reply. > > > > Regards, > > Qinqing > > > > _______________________________________________ > > 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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 11 05:18:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewd3w-00034Y-Sa; Wed, 11 Jan 2006 05:18:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewd3u-00034Q-5J for rohc@megatron.ietf.org; Wed, 11 Jan 2006 05:18:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29690 for ; Wed, 11 Jan 2006 05:17:18 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwdAi-0005mD-DR for rohc@ietf.org; Wed, 11 Jan 2006 05:25:45 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C5FD07BD; Wed, 11 Jan 2006 11:18:00 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 11:18:00 +0100 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 11:17:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC parameter configurations at the radio access network. Date: Wed, 11 Jan 2006 11:17:58 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0501CD551D@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] ROHC parameter configurations at the radio access network. Thread-Index: AcYVcwucoqgSnHmwT+eskjClVqOagAAcWU+QAAgNPCAAI0z1QA== From: "Ghyslain Pelletier \(LU/EAB\)" To: "Kapoor, Rohit" , X-OriginalArrivalTime: 11 Jan 2006 10:17:59.0520 (UTC) FILETIME=[4C287E00:01C61698] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Kapoor, Qinqing Let me try to answer in a more noncommital manner here wrt to 3GPP2, because I was not essentially trying to recommend any specific direction wrt 3GPP2 standardization of C.P0063-0_v1.15. Only the questions where put into this context, so I seem to have fallen into it. In short -- I don't think the proposed parameters will hurt a ROHC implementation. It might only mandate implementing some "features" that are today optional in 3095. I cannot see however that these "features" will help or gain anything. My personal opinion wrt to 3095 Timer-based TS compression is that the gains are insignificant (when any) and that there is very little point in using it (or implementing it for that matter). Reverse decompression is a local feature at the decompressor for which it is also debatable if it is useful at all. IMHO, it's not. This is also because it would anyway be triggered very infrequently, and is likely not suitable for flows with strict delay requirements. This is the essence of my previous mail. Furthermore, I think it is generally a bad idea to add specify signalling external to ROHC implementations, other than the 3095 mandatory channel parameters. I most often simply can't see a good case for this. I could be sympathetic to an argumentation based on that "the octet that it will save for the k packets (k being somewhere close to 2-4 packets) sent with the OA after the DTX period is important because the physical layer payloads are discrete sizes" as Kapoor explained, if only I would believe it would actually solve the problem that this presents, and I believe it does not. The same has been discussed in other standardization bodies. There are too many factors that impact the choice of the compressed header, that requesting the use of Timer-based TS compression gives in fact no guarantee that the size of those header -- i.e. at the beginning of a talkspurt -- will be solely and deterministicly based on the usage of this coding method. =20 I think that the best way with ROHC is to not have any external signalling other than what is necessary for the establishment of the ROHC channel as described in 3095, and instead work your implementation so that it always gives you the best fit for the other constraints presented by the physical layer. But again, it's very much outside my scope (and the one of this list) to go beyond what I wrote above and make recommendations to 3GPP2. I am simply trying to give you the best possible answer according to my understanding, and at this point I think it is up to you guys in 3GPP2 to move on or not with these extra parameters. Best regards, /Ghyslain Kapoor, Rohit wrote: > Ghyslain, >=20 > Thanks for your comments. But, the earlier mail from Qinqing > did not completely explain the procedure in 3GPP2 and let me explain > it.=20 >=20 > Essentially, when the AT acquires the "network" (this is > prior to setting up any flows), it sends the RAN its set of > capabilities. These include whether the RoHC at the AT can do > timer-based compression, delayed decompression etc. >=20 > Once the RAN has this knowledge, it may ask the AT to enable > timer-based compression **only if** the AT has indicated that > it supports it. Else, the RAN will not ask the AT to do > timer-based for any flow. Also, the RAN will typically only > enable timer-based for VoIP flows and not for any other > flows. Moreover, when the RAN asks the AT to enable > timer-based, it only means that the AT's compressor should be > ready to do timer-based (subject of course, to the > decompressor sending a FEEDBACK with the CLOCK option non-zero). >=20 > Similar arguments are also for reverse decompression. Again, > the RAN will only ask the AT to do reverse decompression for > flows which don't have strict delay requirements. If it is > felt by 3GPP2 that gains are not being seen for any flow, > then the RAN can always set this to 0 for all flows. >=20 >=20 > One more point is that the architecture of 3GPP2 is such that > the AT is supposed to be "dumb", meaning that the AT does not > have knowledge of what the flow is. Of course, the AT's > compressor can be smart and try to identify that the flow is > doing Silence Suppression by looking at the RTP stream, but > we have seen cases of implementations where the compressor is > not doing this (or is getting confused while doing this) and > thus, we cannot rely on the AT's compressor to identify this. > The RAN, on the other hand, knows exactly what flow it is, > based on some QoS Profile IDs that are exchanged prior to > setting up the flow. So, the RAN is in the best situation to let the > AT know.=20 >=20 > Also, even though timer-based buys only 1 or 2 bytes > typically (and that too at the beginning of a talkspurt), but > this 1 or 2 bytes becomes very important for us due to the > fact that physical layer payloads are discrete. Meaning that > sometimes even 1 extra byte causes the higher payload to be > picked (which is then mostly padded away), causing a > significant waste in capacity. >=20 >=20 > Let me also stress here that we have been active on this list > and have been following all RoHC guidelines when designing > how to use RoHC in 3GPP2. >=20 > Hope this helps answer your concerns. >=20 > Thanks, > Rohit >=20 >=20 >> -----Original Message----- >> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf >> Of Ghyslain Pelletier (LU/EAB) Sent: Tuesday, January 10, 2006 7:00 >> AM=20 >> To: Qinqing Zhang; rohc@ietf.org >> Subject: RE: [rohc] ROHC parameter configurations at the radio >> access network.=20 >>=20 >> Qinqing, >>=20 >> I had a quick look at C.P0063-0_v1.15 (i.e. the V&V version), section >> 2.9.2.5.1. >> (I assume in this section "supported" means "used for this RoHC >> channel"?)=20 >>=20 >> Comments inline. >>=20 >>> I do not quite see the needs for adding these two attributes at the >>> air interface standards. These two parameters are purely ROHC >>> implementation parameters, which should be handled by the compressor >>> and decompressor, not by RAN, a 3rd party. >>=20 >> I completely agree with you on this. >>=20 >>> The arguments I heard about is that the RAN can make sure that the >>> access terminal will use the timerbased compression for the voice >>> application, and will not use timer based compression for the video >>> application, by setting the TimerBasedCompression attribute for each >>> flow. >>=20 >> These seem to be somewhat rather weak arguments. >>=20 >> First, from IETF specs (3095 + implementer's guide) neither the >> compressor or the decompressor are mandated to implement and support >> timer-based TS compression. Second, for video, the compressor would >> not use it anyway because of the change pattern of the TS that would >> hinder the use of timer-based compression. Thirdly, for voice, the >> gain of timer-based compression is very small (closer to >> insignificant IMHO).=20 >>=20 >> More specifically, from the way 3095 is written and together with the >> clarifications from the implementer's guide (section > section 4.3), it > is >> the decompressor that decides if Timer-based compression MAY be used >> or not by the compressor. The decompressor can signal this that it >> supports timer-based decompression by sending a feedback with a >> CLOCK option. This is then valid for any flow over that RoHC >> channel. In this respect, the decompressor is never mandated to >> implement Timer-based compression. The compressor MAY then (but is >> not mandated to), on a per-context basis, choose to use timer-based >> compression or not - for this the compressor has to send a non-zero >> TIME_STRIDE to the decompressor. In this respect, the compressor is >> never mandated to implement Timer-based compression either.=20 >>=20 >> See also a fine mail by Kristofer S. on this: >> http://www.ietf.org/mail-archive/web/rohc/current/msg04097.html >>=20 >> With respect to the gain of this encoding method, it is mainly only >> applicable to audio flows. Its gain is localized to right after the >> end of a DTX period, at the beginning of the new talkspurt. At this >> point, timer-based compression allows the compressor to send a UOR-2 >> header without any extension, while without timer-based compression >> it would normally have had to send at least a one-byte extension >> (e.g. extension type 0).=20 >>=20 >> The total gain is thus at most 1 byte for a number k of compressed >> packets, where k corresponds to the number of packets sent in UO-mode >> for the optimistic approach (i.e. normally equal to the maximum >> number of consecutive losses over the link). We normally fix the >> value of k to around k =3D 3, so the total gain becomes ... 3 octets >> per talkspurt when compared to not using it.=20 >>=20 >>> Does this make sense? >>=20 >> I am not sure that the suggested parameter is really useful. >>=20 >> First, this mandates that ROHC implementations willing to be >> compliant to 3GPP2 specs shall support timer-based compression, >> which is currently not mandated by IETF specifications as explained >> above, for neither compressor or decompressor.=20 >>=20 >> Second, the gain of timer-based compression is very limited, even >> insignificant with respect to the added complexity of supporting it >> IMHO.=20 >>=20 >> So, would 3GPP2 really feels that these few octets are worth the >> fight, then it should at least mandate RoHC implementations to >> explicitely support Timer-based compression. But this is not >> something that I would recommend to do anyway.=20 >>=20 >>> Another question is that for this delayed compression, is there any >>> implementation issue that this option is actually not recommended? >>=20 >> I assume that delayed compression refers to the reverse compression >> of 3095, section 6.1. I am not sure what potential implementation >> issue you are referring to, but reverse decompression is definitely >> purely an implementation feature for the decompressor and IMHO it >> should not be mandated to support.=20 >>=20 >> Secondly, I wonder what is the purpose of having a parameter for >> specifying reverse decompression? Is it meant as a "hint" for the >> decompressor? If so, is it a hint for the purpose of indicating some >> kind of maximum delay requirement? Otherwise, what prevents a >> decompressor to ignore this parameter altogether and not perform >> reverse decompression at all?=20 >>=20 >> Finally, it seems to me that it is rather likely that the actual >> depth for being successful with this "feature" would exceed the delay >> requirements of the real-time flow(s). This is because the >> decompressor must store all packets that have not successfully been >> decompressed until a UOR-2, IR, or IR-DYN that solves the problem is >> received, and these are normally infrequently sent by the compressor >> - mainly only when feedback is received for a context repair. >>=20 >> In other words, I normally don't recommend the use of reverse >> decompression at any time.=20 >>=20 >> So, in short, I would suggest that these two parameters not be >> included in C.P0063-0, but on the other end I do not believe that >> they will hurt anything other than mandating the use of timer-based >> compression for all implementers. >> MaxSupportedDelayedDecompressionDepth will have in my opinion no >> effect. =20 >>=20 >> I hope this helps you somewhat, >>=20 >> Regards, >>=20 >> /Ghyslain >>=20 >> rohc-bounces@ietf.org wrote: >>> Dear ROHC experts: >>>=20 >>> In a recent 3GPP2 standard document, TIA-1054 (not the final >>> version), there is a proposal to add two attributes related with >>> ROHC parameters configurated at the air interface. The two >>> attributes are TimerBasedCompression, and DelayCompressionDepth. The >>> description of these two attributes are > as >>> follows: >>>=20 >>> DelayCompressionDepth: >>> The sender shall set this field to the maximum number of packets >>> that can be buffered and thus possibly be delayed decompressed by >>> the decompressor according to ROHC RFC3095 for this ROHC channel. If >>> the value of this field is 0, then delayed compression shall not be >>> enabled. The sender shall not set this field to a value greater than >>> MaxSupportedDelayedDecompressionDepth. >>>=20 >>> TimerBasedCompression: >>> The sender shall set this field to "0" if timer based compression is >>> not enabled for this ROHC channel. The sender shall set this field >>> to "1" if timer based compression is enabled for this ROHC channel. >>> If TimerBasedCompressionSupported is set to "0", then the sender >>> shall not set this field to "1". >>>=20 >>> I do not quite see the needs for adding these two attributes at the >>> air interface standards. These two parameters are purely ROHC >>> implementation parameters, which should be handled by the compressor >>> and decompressor, not by RAN, a 3rd party. The arguments I heard >>> about is that the RAN can make sure that the access terminal will >>> use the timerbased compression for the voice application. and will >>> not use timer based compression for the video application, by >>> setting the TimerBasedCompression attribute for each flow. >>> Does this make sense? >>> Another question is that for this delayed compression, is there any >>> implementation issue that this option is actually not recommended? >>>=20 >>> I do not intend to bring the discussion from 3GPP2 standards to the >>> IETF standards. But since this is related with ROHC, I would like to >>> seek the opinion from the IETF ROHC experts. >>>=20 >>> Thanks in advance for your kind reply. >>>=20 >>> Regards, >>> Qinqing >>>=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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 12 19:18:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCeK-0004Rz-PG; Thu, 12 Jan 2006 19:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCeI-0004Ql-Bm for rohc@megatron.ietf.org; Thu, 12 Jan 2006 19:18:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12061 for ; Thu, 12 Jan 2006 19:17:13 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExClU-0002hH-0z for rohc@ietf.org; Thu, 12 Jan 2006 19:26:01 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7FDDD5D6; Fri, 13 Jan 2006 01:18:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 01:18:31 +0100 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 01:18:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2006 01:18:29 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05021D17BE@esealmw109.eemea.ericsson.se> Thread-Topic: WGLC Reveiw RFC3095 Implementer's guide Thread-Index: AcYVywdCmeYKNLzYREOXYtb2h/pAdwCCbexg From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Carl Knutsson" , X-OriginalArrivalTime: 13 Jan 2006 00:18:30.0917 (UTC) FILETIME=[E206BB50:01C617D6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: Subject: [rohc] RE: WGLC Reveiw RFC3095 Implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Carl, Thanks for the review, responses inline... Rgds, /L-E > Lars-Erik, all, >=20 > Over all, I am pretty pleased with ROHC Implementer's guide. > I have some comments... >=20 > When referring to a section to another document, you have to > specify the document, not just the section. It is not clear if > it refers to this document (Implementer's guide) or the rfc3095. > Maybe this is common practice for updating rfcs. The introduction clearly says: "Note that all section and chapter references in this document refer to [1], where not stated otherwise." The reason is that all issues brought up in this document are about 3095 (where not explicitly stated otherwise). I will make sure we make clear when references are within this document. ->> Will check in-document references! =20 > Section 8.10: >=20 > It could be worth to mention that this section applies to profile 3 > (ESP) too. rfc3095 section 5.12.2 specifies that profile 3 > uses the same packet formats as profile 2. It wouldn't hurt to > write it one more time. True, I will modify that to say profile 2 (UDP) and 3 (ESP) ->> Modify section heading and text in 8.10 > Section 8.13: > " Sequence Number: Not sent when the offset from the sequence number > of the compressed header is constant. When the > offset is not constant, the sequence number is > compressed by sending LSBs. See 5.8.4." >=20 > The reference to section 5.8.4 is a bit confusing. At least until I > realized that the text is copied from rfc3095. Please include a > reference to rfc3095 in this section. Quotation marks are used in > earlier sections, it could be used here too. Good observation, I will add that. ->> Add "from section 5.8.4.3" between "rule" and "applies". =20 > In section 6.2 and 8.3, I believe it should be explained that the > context is updated with index-item pairs for UO-1-ID with extension3. > It could be added as a reference to section 5.4. True! ->> Add reminding pointer to This:5.4 in both 6.2 and 8.3. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Jan 13 20:20:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exa6F-00026o-CM; Fri, 13 Jan 2006 20:20:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exa6D-00026Z-30; Fri, 13 Jan 2006 20:20:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28281; Fri, 13 Jan 2006 20:19:35 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExaDc-0005cd-5z; Fri, 13 Jan 2006 20:28:37 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0E1JIi03216; Fri, 13 Jan 2006 17:19:18 -0800 (PST) Message-Id: <200601140119.k0E1JIi03216@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 13 Jan 2006 17:19:18 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: rohc@ietf.org, rfc-editor@rfc-editor.org Subject: [rohc] RFC 4224 on RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4224 Title: RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets Author(s): G. Pelletier, L-E. Jonsson, K. Sandlund Status: Informational Date: January 2006 Mailbox: ghyslain.pelletier@ericsson.com, lars-erik.jonsson@ericsson.com, kristofer.sandlund@ericsson.com Pages: 21 Characters: 49416 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rohc-over-reordering-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4224.txt RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. This document is a product of the Robust Header Compression Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060113171803.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4224 --OtherAccess Content-Type: Message/External-body; name="rfc4224.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060113171803.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Fri Jan 20 04:39:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezsjq-0003bH-6S; Fri, 20 Jan 2006 04:39:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezsjo-0003bC-Qd for rohc@megatron.ietf.org; Fri, 20 Jan 2006 04:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25349 for ; Fri, 20 Jan 2006 04:37:53 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzssR-00057T-Ir for rohc@ietf.org; Fri, 20 Jan 2006 04:48:21 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 671914F0007 for ; Fri, 20 Jan 2006 10:37:36 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 10:37:36 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 10:37:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2006 10:35:09 +0100 Message-ID: Thread-Topic: ROHC-TCP: Proposed changes to the packet formats Thread-Index: AcYdpSPSMJsjzy5gQZufkGBZUELpiQ== From: "Kristofer Sandlund \(LU/EAB\)" To: X-OriginalArrivalTime: 20 Jan 2006 09:37:35.0612 (UTC) FILETIME=[251D3BC0:01C61DA5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: [rohc] ROHC-TCP: Proposed changes to the packet formats X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Hi all, A long-overdue walkthrough of the "_replicate" formats in ROHC-TCP found a few things that I think should be changed in the formats. Here's a list of proposed changes: - GRE: The r_flag, which is deprecated in RFC2784 should not be handled as "irregular", since we have no idea of how future versions might define this bit (and backward compatibility with 1701=20 seems redundant?). Future versions of GRE _could_ define that bit so=20 that it adds some extension field to the header, and therefore we=20 should only compress packets where this is set to zero. Same argument goes for the version field of GRE (change it to=20 uncompressed_value instead of irregular) - We decided long ago that replication formats should never use LSB = encoding in a replicate format when the base field is changing due to the risk of race conditions, and I noticed that we had some of these=20 encodings in GRE, AH and ESP sequence numbers and therefore suggest=20 dropping these and replace them with the irregular format for these=20 sequence numbers. - The IPv6 replicate format always replicates the flow_label, which seems like quite a bad strategy, since this means that the flow label must be identical if replication is to be possible. Therefore, I suggest changing so that the flow label can be replicated only if it is zero, otherwise flow label is is sent as irregular. - The two replicate formats for IPv4 did not make much sense. The=20 difference between them was only that the second format could send=20 ip_id_behavior, df and ttl/hoplimit. Quick inspection showed that the smaller format had 7 free bits from the discriminator, so I suggest using 3 of these for behavior and df, and let one more bit be an indicator flag if the ttl should be replicated or not and therefore we can merge both these formats. This is a pure optimization and even though I'm removing one format it does not remove any capability from the replication. So, unless I hear objections, these changes will go into the next revision of the draft. BR, Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Jan 23 18:50:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1BS9-0004nS-GI; Mon, 23 Jan 2006 18:50:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1BRl-0004fa-2f; Mon, 23 Jan 2006 18:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05211; Mon, 23 Jan 2006 18:48:35 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1BbA-0003cm-R4; Mon, 23 Jan 2006 18:59:49 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F1BRi-0007Pe-IN; Mon, 23 Jan 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Jan 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-17.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org --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 : The RFC 3095 Implementer's Guide Author(s) : L. Jonsson, et al. Filename : draft-ietf-rohc-rtp-impl-guide-17.txt Pages : 24 Date : 2006-1-23 RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP, UDP, RTP, and ESP. This document clarifies ambiguities and common misinterpretations of RFC 3095, and it also corrects some actual errors in the specification. The corrections and clarifications provided herein must be followed to get interoperable implementations, i.e. this document updates RFC 3095. Further, minor interpretation details of RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles) are also addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-17.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rtp-impl-guide-17.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-rtp-impl-guide-17.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: <2006-1-23174726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-23174726.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Wed Jan 25 02:40:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fGP-0005MY-4N; Wed, 25 Jan 2006 02:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fGM-0005MT-NV for rohc@megatron.ietf.org; Wed, 25 Jan 2006 02:40:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17616 for ; Wed, 25 Jan 2006 02:38:47 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1fPw-0005OM-6A for rohc@ietf.org; Wed, 25 Jan 2006 02:50:21 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5CF7E4F0001 for ; Wed, 25 Jan 2006 08:39:59 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 08:39:59 +0100 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 08:39:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2006 08:40:10 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05023211D8@esealmw109.eemea.ericsson.se> Thread-Topic: I-D ACTION:draft-ietf-rohc-rtp-impl-guide-17.txt Thread-Index: AcYgek9GYE54ZX05SZisuQK9onxNTwBB8J1A From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 25 Jan 2006 07:39:59.0249 (UTC) FILETIME=[8B427010:01C62182] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Subject: [rohc] RE: I-D ACTION:draft-ietf-rohc-rtp-impl-guide-17.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org The draft has been updated to address the comments received during WGLC. We are currently discussing with our AD which target document class to have for this draft, Standards Track or Informational, I'll get back about that later on. Cheers, /L-E > 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. >=20 > Title : The RFC 3095 Implementer's Guide > Author(s) : L. Jonsson, et al. > Filename : draft-ietf-rohc-rtp-impl-guide-17.txt > Pages : 24 > Date : 2006-1-23 >=20 > RFC 3095 defines the RObust Header Compression (ROHC) framework and > profiles for IP, UDP, RTP, and ESP. This document clarifies > ambiguities and common misinterpretations of RFC 3095, and it also > corrects some actual errors in the specification. The > corrections and > clarifications provided herein must be followed to get > interoperable implementations, i.e. this document updates RFC 3095. > Further, minor > interpretation details of RFC 3241 (ROHC over PPP), RFC 3843 (ROHC > IP profile) and RFC 4109 (ROHC UPD-Lite profiles) are also > addressed.=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-g > uide-17.txt=20 >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > 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-rtp-impl-guide-17.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-17.txt". >=20 > 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. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 25 20:50:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1wHS-0003vo-7m; Wed, 25 Jan 2006 20:50:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1wHP-0003vI-RK; Wed, 25 Jan 2006 20:50:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22152; Wed, 25 Jan 2006 20:49:00 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1wRG-0005P8-3p; Wed, 25 Jan 2006 21:00:43 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0Q1n2623513; Wed, 25 Jan 2006 17:49:02 -0800 (PST) Message-Id: <200601260149.k0Q1n2623513@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 25 Jan 2006 17:49:01 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: rohc@ietf.org, rfc-editor@rfc-editor.org Subject: [rohc] RFC 4362 on RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4362 Title: RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP Author(s): L-E. Jonsson, G. Pelletier, K. Sandlund Status: Standards Track Date: January 2006 Mailbox: lars-erik.jonsson@ericsson.com, ghyslain.pelletier@ericsson.com, kristofer.sandlund@ericsson.com Pages: 23 Characters: 53926 Obsoletes: 3242 I-D Tag: draft-ietf-rohc-rfc3242bis-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4362.txt This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes. This document is a product of the Robust Header Compression Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060125174746.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4362 --OtherAccess Content-Type: Message/External-body; name="rfc4362.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060125174746.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Tue Jan 31 07:45:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3usf-0008Jt-8B; Tue, 31 Jan 2006 07:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3usW-0008H5-ND for rohc@megatron.ietf.org; Tue, 31 Jan 2006 07:45:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12041 for ; Tue, 31 Jan 2006 07:43:14 -0500 (EST) Received: from www.nabble.com ([72.21.53.35] helo=talk.nabble.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3v3G-0001Oh-4x for rohc@ietf.org; Tue, 31 Jan 2006 07:56:10 -0500 Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1F3us9-0006Nr-LG for rohc@ietf.org; Tue, 31 Jan 2006 04:44:37 -0800 Message-ID: <2679064.post@talk.nabble.com> Date: Tue, 31 Jan 2006 04:44:37 -0800 (PST) From: "Sofiur Rahman Siddique (sent by Nabble.com)" To: rohc@ietf.org Subject: Re: [rohc] Sigcomp Torture Test discrepancy In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80016D9A00@svr-exchange.avocado.emccsoft.com> MIME-Version: 1.0 X-Nabble-Sender: Nabble Forums X-Nabble-From: Sofiur Rahman Siddique References: <22C8A0D5D5E095449AB509FE777B5F80016D9A00@svr-exchange.avocado.emccsoft.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sofiur Rahman Siddique List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1162126278==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org --===============1162126278== Content-Type: multipart/alternative; boundary="----=_Part_5596_14655524.1138711477653" ------=_Part_5596_14655524.1138711477653 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I am facing problem in the first test itself. at (64) :a pad (2) :b pad (2) at (128) JUMP (start) ; Jump to address 255 at (255) :start AND ($start, 21845) ; 448 & 21845 = 320 = 0x0140 OR ($a, 42) ; 0 | 42 = 42 = 0x002a NOT ($b) ; ~0 = 65535 = 0xffff LSHIFT ($a, 3) ; 42 << 3 = 336 = 0x0150 RSHIFT ($b, 65535) ; 65535 >> 65535 = 0 = 0x0000 OUTPUT (64, 4) ; Output 0x0150 0000 The OUTPUT instruction tries to output 4 bytes from UDVM memory address 64. The current values are 0x0150 and 0x0000. These values sets byte_copy_left and byte_copy_right values as 0x0150 and 0x0000 respectively implying byte_copy_left value is greater than byte_copy_right. My code gives an SEGFAULT (violation of rule 8.4) here. In most of the torture test cases this is the problem I am facing. Can anybody give light to me in the byte copy rule. Regards Siddique -- View this message in context: http://www.nabble.com/Sigcomp-Torture-Test-discrepancy-t787961.html#a2679064 Sent from the IETF - Rohc forum at Nabble.com. ------=_Part_5596_14655524.1138711477653 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

I am facing problem in the first test itself.

 at (64)
 :a                              pad (2)
 :b                              pad (2)
 at (128)
 JUMP (start)            ; Jump to address 255
 at (255)
 :start
 AND ($start, 21845)     ; 448 & 21845 = 320 = 0x0140
 OR ($a, 42)             ; 0 | 42 = 42 = 0x002a
 NOT ($b)                ; ~0 = 65535 = 0xffff
 LSHIFT ($a, 3)          ; 42 << 3 = 336 = 0x0150
 RSHIFT ($b, 65535)      ; 65535 >> 65535 = 0 = 0x0000

 OUTPUT (64, 4)          ; Output 0x0150 0000

The OUTPUT instruction tries to output 4 bytes from UDVM memory address 64.
The current values are 0x0150 and 0x0000.
These values sets byte_copy_left and byte_copy_right values as 0x0150 and 0x0000 respectively implying byte_copy_left value is greater than byte_copy_right.
My code gives an SEGFAULT (violation of rule 8.4) here.
In most of the torture test cases this is the problem I am facing.
Can anybody give light to me in the byte copy rule.

Regards
Siddique

View this message in context: Re: Sigcomp Torture Test discrepancy
Sent from the IETF - Rohc forum at Nabble.com. ------=_Part_5596_14655524.1138711477653-- --===============1162126278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1162126278==-- From rohc-bounces@ietf.org Tue Jan 31 08:56:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3vzi-0003LA-KJ; Tue, 31 Jan 2006 08:56:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3vze-0003Jc-Hd for rohc@megatron.ietf.org; Tue, 31 Jan 2006 08:56:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17775 for ; Tue, 31 Jan 2006 08:54:39 -0500 (EST) Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3wAN-0003pW-1F for rohc@ietf.org; Tue, 31 Jan 2006 09:07:36 -0500 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3]) by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id k0VDjY710871 for ; Tue, 31 Jan 2006 13:45:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] Sigcomp Torture Test discrepancy Date: Tue, 31 Jan 2006 13:53:41 -0000 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8001993FED@svr-exchange.avocado.emccsoft.com> Thread-Topic: [rohc] Sigcomp Torture Test discrepancy Thread-Index: AcYmZMtIBm4DI/LzTX2TSSqeqK3nrgAB/5hA From: "John Barber" To: "Sofiur Rahman Siddique" , X-Spam-Score: 0.9 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0225387356==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============0225387356== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6266D.BE72BB9E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6266D.BE72BB9E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Siddique, =20 Byte copying rules should not affect the OUTPUT instruction in this case. =20 The byte copying rule is discussed in a bit more detail in http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-0 5.txt, section 4. I think if you take a look at that it should make things clear. =20 Regards, John ________________________________ From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf Of Sofiur Rahman Siddique (sent by Nabble.com) Sent: 31 January 2006 12:45 To: rohc@ietf.org Subject: Re: [rohc] Sigcomp Torture Test discrepancy =09 =09 Hi All,=20 =09 I am facing problem in the first test itself.=20 =09 at (64)=20 :a pad (2)=20 :b pad (2)=20 at (128)=20 JUMP (start) ; Jump to address 255=20 at (255)=20 :start=20 AND ($start, 21845) ; 448 & 21845 =3D 320 =3D 0x0140=20 OR ($a, 42) ; 0 | 42 =3D 42 =3D 0x002a=20 NOT ($b) ; ~0 =3D 65535 =3D 0xffff=20 LSHIFT ($a, 3) ; 42 << 3 =3D 336 =3D 0x0150=20 RSHIFT ($b, 65535) ; 65535 >> 65535 =3D 0 =3D 0x0000=20 =09 OUTPUT (64, 4) ; Output 0x0150 0000=20 =09 The OUTPUT instruction tries to output 4 bytes from UDVM memory address 64.=20 The current values are 0x0150 and 0x0000.=20 These values sets byte_copy_left and byte_copy_right values as 0x0150 and 0x0000 respectively implying byte_copy_left value is greater than byte_copy_right.=20 My code gives an SEGFAULT (violation of rule 8.4) here.=20 In most of the torture test cases this is the problem I am facing.=20 Can anybody give light to me in the byte copy rule.=20 =09 Regards=20 Siddique=20 =09 =09 ________________________________ View this message in context: Re: Sigcomp Torture Test discrepancy =20 Sent from the IETF - Rohc forum at Nabble.com.=20 ------_=_NextPart_001_01C6266D.BE72BB9E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Siddique,
 
Byte copying rules should not affect the OUTPUT = instruction=20 in this case.
 
The byte copying rule is discussed in a bit = more detail in=20 http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp= -impl-guide-05.txt,=20 section 4. I think if you take a look at that it should make things=20 clear.
 
Regards, John

From: rohc-bounces@ietf.org=20 [mailto:rohc-bounces@ietf.org] On Behalf Of Sofiur Rahman = Siddique=20 (sent by Nabble.com)
Sent: 31 January 2006 = 12:45
To:=20 rohc@ietf.org
Subject: Re: [rohc] Sigcomp Torture Test=20 discrepancy

Hi All,

I am facing problem in the first test = itself.=20

 at (64)
 :a           =  =20                  pad (2)=20
 :b                 =  =20            pad (2)
 at (128)=20
 JUMP (start)            ; Jump = to=20 address 255
 at (255)
 :start
 AND ($start, = 21845)=20     ; 448 & 21845 =3D 320 =3D 0x0140
 OR ($a, = 42)  =20           ; 0 | 42 =3D 42 =3D 0x002a =
 NOT ($b)=20                ; ~0 =3D 65535 = =3D 0xffff=20
 LSHIFT ($a, 3)          ; 42=20 << 3 =3D 336 =3D 0x0150
 RSHIFT ($b, 65535)   =  =20  ; 65535 >> 65535 =3D 0 =3D 0x0000

 OUTPUT = (64, 4)  =20        ; Output 0x0150 0000

The OUTPUT = instruction=20 tries to output 4 bytes from UDVM memory address 64.
The current = values=20 are 0x0150 and 0x0000.
These values sets byte_copy_left and=20 byte_copy_right values as 0x0150 and 0x0000 respectively implying=20 byte_copy_left value is greater than byte_copy_right.
My code = gives an=20 SEGFAULT (violation of rule 8.4) here.
In most of the torture test = cases=20 this is the problem I am facing.
Can anybody give light to me in = the byte=20 copy rule.

Regards
Siddique

View this message in context: Re:=20 Sigcomp Torture Test discrepancy
Sent from the IETF - Rohc = forum at=20 Nabble.com. ------_=_NextPart_001_01C6266D.BE72BB9E-- --===============0225387356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0225387356==-- From rohc-bounces@ietf.org Tue Jan 31 13:09:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zwP-0008KS-Bc; Tue, 31 Jan 2006 13:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zwN-0008I3-91 for rohc@megatron.ietf.org; Tue, 31 Jan 2006 13:09:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14225 for ; Tue, 31 Jan 2006 13:07:43 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F407M-0006K0-6l for Rohc@ietf.org; Tue, 31 Jan 2006 13:20:42 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k0VINYK2023367 for ; Tue, 31 Jan 2006 11:23:34 -0700 (MST) Received: from zuk35exm63.ds.mot.com (zuk35exm63.ea.mot.com [10.178.1.42]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k0VIN26p000262 for ; Tue, 31 Jan 2006 12:23:02 -0600 (CST) Received: from [127.0.0.1] ([10.161.4.142]) by zuk35exm63.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 18:09:00 +0000 Message-ID: <43DFA7BA.8090800@motorola.com> Date: Tue, 31 Jan 2006 19:08:58 +0100 From: =?ISO-8859-1?Q?Joel_Centelles_Mart=EDn?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rohc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 31 Jan 2006 18:09:00.0285 (UTC) FILETIME=[692602D0:01C62691] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate8.mot.com id k0VINYK2023367 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: Subject: [rohc] About RFC3321 SigComp Extensions X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Hi All, I'm currently working with the RFC3321 SigComp Extensions and I faced=20 the following problem: Implementing a sharing compression mechanism seems not to be hard work=20 (draft-ietf-rohc-sigcomp-user-guide-04 gives a good way of doing it),=20 the problem that I found is: Is there any compression algorithm that=20 takes advantage of shared compression? I mean, is possible to implement=20 the mechanism, store and access to the state in both sides, but, does=20 anybody know about a compression algorithm that uses this information to=20 improve compression rates? I've been searching in the web but found=20 nothing about a compression algorithm of these characteristics. About the same problem, do you know if there is anybody working to=20 achieve it or to adapt an existing one to use it? Thanks in advance, Jo=EBl . _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc