From rohc-bounces@ietf.org Wed May 03 09:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHNO-0007zh-PX; Wed, 03 May 2006 09:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHNN-0007zc-RP for Rohc@ietf.org; Wed, 03 May 2006 09:26:45 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbHNL-0008H5-HZ for Rohc@ietf.org; Wed, 03 May 2006 09:26:45 -0400 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYO00HB6YFYZT@usaga01-in.huawei.com> for Rohc@ietf.org; Wed, 03 May 2006 06:21:34 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYO002UWZ9HY9@szxga02-in.huawei.com> for Rohc@ietf.org; Wed, 03 May 2006 21:39:18 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYO00IM4Z9H5D@szxga02-in.huawei.com> for Rohc@ietf.org; Wed, 03 May 2006 21:39:17 +0800 (CST) Received: from htiplSASHIDHAR ([10.18.5.55]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYO00FWWZ93H8@szxml02-in.huawei.com> for Rohc@ietf.org; Wed, 03 May 2006 21:39:04 +0800 (CST) Date: Wed, 03 May 2006 18:54:40 +0530 From: jakki sasidhar To: Rohc@ietf.org Message-id: <000001c66eb4$ef6e7500$3705120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [rohc] Query on Sigcomp UDVM Sorting instruction X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jakkis@huawei.com List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0298357099==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============0298357099== Content-type: multipart/alternative; boundary="Boundary_(ID_SwmDJkiveWrBxLfB522cXw)" This is a multi-part message in MIME format. --Boundary_(ID_SwmDJkiveWrBxLfB522cXw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, Is it valid for sorting instruction to have n =1 i.e there is only one list supplied to it? There is not much information about the usage of these UDVM instructions in any compression algorithm. So it will be appreciated if anyone can clarify this one. with regards, Sasidhar **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_SwmDJkiveWrBxLfB522cXw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
Hi All,
    Is it valid for sorting instruction to have n =1 i.e there is only one list supplied to it? There is not much information about the usage of these UDVM instructions in any compression algorithm. So it will be appreciated if anyone can clarify this one.
 
with regards,
Sasidhar
 

***************************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 
--Boundary_(ID_SwmDJkiveWrBxLfB522cXw)-- --===============0298357099== 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 --===============0298357099==-- From rohc-bounces@ietf.org Thu May 04 12:10:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgPD-0003ZC-4d; Thu, 04 May 2006 12:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgPC-0003Yy-3I; Thu, 04 May 2006 12:10:18 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbgPB-0001uX-LF; Thu, 04 May 2006 12:10:18 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:52716) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FbgPB-0000Hx-9C; Thu, 04 May 2006 17:10:17 +0100 Mime-Version: 1.0 (Apple Message framework v749.3) References: <28A58523-F3F5-483E-9763-9E2D5329914F@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88B272E0-B615-46C9-B608-6AC19B11189A@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 4 May 2006 17:10:14 +0100 To: rohc@ietf.org, mpls@ietf.org, pwe3@ietf.org X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [rohc] Fwd: Working group last call: draft-ietf-avt-hc-over-mpls-protocol-05.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: IETF AVT WG List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Folks, The following working group last call has just been issued in AVT, but overlaps with the MPLS, ROHC, and PWE3 working groups. We would be grateful for review from those working groups: please send any comments on the draft to the mailing list. Thanks, Colin (AVT co-chair) Begin forwarded message: > From: Colin Perkins > Date: 4 May 2006 17:06:19 BDT > To: IETF AVT WG > Subject: Working group last call: draft-ietf-avt-hc-over-mpls- > protocol-05.txt > > This is to announce a working group last call on the Protocol > Extensions for Header Compression over MPLS mpls-protocol-05.txt>. Please send any final comments on this draft > to the avt@ietf.org mailing list by 22nd May 2006. If no issues are > raised by that time, we will request the IESG consider this for > publication as a proposed standard RFC. > > Colin > > > > On 3 May 2006, at 20:50, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Audio/Video Transport Working >> Group of the IETF. >> >> Title : Protocol Extensions for Header Compression over MPLS >> Author(s) : J. Ash, et al. >> Filename : draft-ietf-avt-hc-over-mpls-protocol-05.txt >> Pages : 30 >> Date : 2006-5-3 >> >> VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS >> labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an >> MPLS VPN, the packet header is typically 48 bytes, while the voice >> payload is often no more than 30 bytes, for example. Header >> compression can significantly reduce the overhead through various >> compression mechanisms. MPLS is used to route header-compressed (HC) >> packets over an MPLS LSP without compression/decompression cycles at >> each router. Such an HC over MPLS capability increases the bandwidth >> efficiency as well as processing scalability of the maximum number of >> simultaneous compressed flows that use HC at each router. MPLS >> pseudowires are used to transport the HC context and other control >> messages between the ingress and egress MPLS label switched router >> (LSR). Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to >> determine the context. Each HC scheme operates over a single >> pseudowire instance very much like it would over a single >> point-to-point link. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls- >> protocol-05.txt _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 08 09:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd5cy-00019C-Pa; Mon, 08 May 2006 09:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd5cx-000197-QU for rohc@ietf.org; Mon, 08 May 2006 09:18:19 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd5cv-0007vi-US for rohc@ietf.org; Mon, 08 May 2006 09:18:19 -0400 Received: from Sarvamangala (sarvamangala.globaledgesoft.com [172.16.2.248] (may be forged)) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with SMTP id k48DI9Ql017073 for ; Mon, 8 May 2006 18:48:10 +0530 Message-ID: <001401c672a1$da7e9df0$f80210ac@ges> From: "Sarvamangala" To: Date: Mon, 8 May 2006 18:48:09 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1147093909" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [rohc] freely available sip server/client to test sigcomp? 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: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1147093909 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C672CF.F38404B0" This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C672CF.F38404B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 I would like to know if there any freely available sip server or client = supporting sigcomp.=20 This is needed for interoperabilty test. Regards, Sarvamangala ------=_NextPart_000_0011_01C672CF.F38404B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I would like to know if there = any freely=20 available sip server or client supporting sigcomp.
This is needed for interoperabilty=20 test.
 
Regards,
Sarvamangala
 
------=_NextPart_000_0011_01C672CF.F38404B0-- ------=neXtPaRt_1147093909 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1147093909 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_1147093909-- From rohc-bounces@ietf.org Tue May 09 02:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLmf-0002N9-DE; Tue, 09 May 2006 02:33:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLmd-0002J2-Py for rohc@ietf.org; Tue, 09 May 2006 02:33:23 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdLmb-0005Zc-HA for rohc@ietf.org; Tue, 09 May 2006 02:33:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 26A5490003 for ; Tue, 9 May 2006 02:33:21 -0400 (EDT) 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 25518-09 for ; Tue, 9 May 2006 02:33:17 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 9 May 2006 02:33:17 -0400 (EDT) Received: from EXCHINDIA2.starentnetworks.com ([10.4.2.4]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 May 2006 02:31:12 -0400 Received: from exchindia3.starentnetworks.com ([10.6.0.5]) by EXCHINDIA2.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 May 2006 12:01:08 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 May 2006 12:01:19 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Message-ID: <69FADB84C90B1248A7DE59422771FA0C054D0A@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rohc over gre Thread-Index: AcZzMhSv68VRGXf8QA6TdhEbdNemWA== From: "Sarkar, Biplab" To: X-OriginalArrivalTime: 09 May 2006 06:31:08.0845 (UTC) FILETIME=[284ECDD0:01C67332] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [rohc] rohc over gre 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="===============1816759978==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1816759978== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67332.27B5F57A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67332.27B5F57A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Is there any RFC for ROHC-over-GRE tunnel. I mean "non-PPP" based ROHC.=20 =20 Thanks Biplab ------_=_NextPart_001_01C67332.27B5F57A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Is there any RFC for = ROHC-over-GRE tunnel. I mean “non-PPP” based ROHC. =

 

Thanks

Biplab

------_=_NextPart_001_01C67332.27B5F57A-- --===============1816759978== 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 --===============1816759978==-- From rohc-bounces@ietf.org Tue May 09 04:24:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdNVs-0004YB-VG; Tue, 09 May 2006 04:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdNVr-0004Y6-KD for rohc@ietf.org; Tue, 09 May 2006 04:24:11 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdNVq-000223-Bc for rohc@ietf.org; Tue, 09 May 2006 04:24:11 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k498O570001424 for ; Tue, 9 May 2006 03:24:05 -0500 (CDT) Received: from [135.252.136.83] ([135.252.136.83]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k498O3M07433; Tue, 9 May 2006 03:24:04 -0500 (CDT) Message-ID: <44605178.906@lucent.com> Date: Tue, 09 May 2006 16:23:20 +0800 From: Carrie Zhang User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [rohc] accept SMS=0 or not? 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: , Errors-To: rohc-bounces@ietf.org Hi, experts, I have a couple of questions regarding the case where SMS=0. 3GPP specifies that both UE (User Equipment) and network side should support minimum 4K of SMS when implementing SIP compression, according to 3GPP, SMS=0 is not acceptable. While there are some special cases: Case 1: UE may first advertise its SMS>=4k, and later use SMS=0 to indicate that all states have been lost, in this case, should network side accept this SMS=0? Option 1: Network side would assume that this is an error in UE and only lasts for very short time, and network side can switch to sending bytecode just as UE is stateless. When UE recovers from the failure and advertises again its SMS with non-zero value, network can then switch back to whatever compression it used before receiving SMS=0. But what if UE can not recover from the failure, and keep sending SMS=0? Should network accept this? Option 2: Network side can always treat SMS=0 as error because 3GPP says min SMS is 4K, and responds uncompressed message regardless whether the topmost via header contains comp=sigcomp in the incoming message with SMS=0. Case 2: If UE never advertises its SMS with non-zero value, and in the 1st message, the SMS is zero, should network side accept this message? Option 1: If network side accepts this message, it disobeys 3GPP technical specification. Option 2: If network side does not accept this message, this may cause other problems, e.g., my phone is broken for some unknown reason (SMS memory broken) and it sends out SMS=0 in the 1st message and I need to make an emergency call. Now if the network side does not allow that, I think it is not acceptable. Appreciate any of your advices? Thanks in advance. Regards, Carrie _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 09 05:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOA7-00045d-P1; Tue, 09 May 2006 05:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOA6-00045X-FW for rohc@ietf.org; Tue, 09 May 2006 05:05:46 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdOA5-0004RU-2l for rohc@ietf.org; Tue, 09 May 2006 05:05:46 -0400 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k4995QCg002528; Tue, 9 May 2006 11:05:26 +0200 (CEST) In-Reply-To: <44605178.906@lucent.com> References: <44605178.906@lucent.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <081A468E-16D6-4876-A480-4C118DD4319C@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] accept SMS=0 or not? Date: Tue, 9 May 2006 11:05:25 +0200 To: Carrie Zhang X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Carsten Bormann , 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: , Errors-To: rohc-bounces@ietf.org On May 09 2006, at 10:23 , Carrie Zhang wrote: > Option 1: If network side accepts this message, it disobeys 3GPP > technical specification. I don't think this view would be right. If I understand your scenario right, from an RFC3320 point of view, SMS=0 is perfectly valid. Nothing will break by implementing the reception of this value. In essence, requiring SMS>0 is a performance requirement, not an interoperability requirement. Rejecting a peer that you could perfectly interoperate with just on the grounds that they violated some performance specification is not the way of the Internet. RFC 1123 famously summarizes the Internet robustness principle as: "Be liberal in what you accept, and conservative in what you send" So, in your example, the onus is on the handset to send the SMS value as mandated, not on the network to somehow enforce this. (This argument would go into a different direction if SMS=0 would actually cause things to break.) For diagnostic purposes, you might still want to log the out-of-range SMS value. (Speaking from unhappy experience:) Now, of course, the people who write the test suites that your implementation will be judged against may not understand all this and actually require your implementation to break in this case. (Or they may require you to handle the case according to RFC3320. You never know what you'll get in a test suite.) But you asked this on an IETF mailing list... Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 09 11:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdU71-0003Um-2z; Tue, 09 May 2006 11:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdU6y-0003UD-RT for rohc@ietf.org; Tue, 09 May 2006 11:26:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdTz8-0005aB-7C for rohc@ietf.org; Tue, 09 May 2006 11:18:50 -0400 Received: from [61.135.132.105] (helo=smtp128.sohu.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdThQ-0008Rd-0w for rohc@ietf.org; Tue, 09 May 2006 11:00:34 -0400 Received: from 4906fca4 (unknown [220.234.72.190]) by smtp128.sohu.com (Postfix) with ESMTP id 9DA8C0036744 for ; Tue, 9 May 2006 23:00:14 +0800 (CST) From: "chen xionggui" To: Date: Tue, 9 May 2006 23:00:12 +0800 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 2.5 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [rohc] (no subject) 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="===============0671291551==" Errors-To: rohc-bounces@ietf.org --===============0671291551== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGk6DQoJSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgcmVmcmVuY2UgbGlzdCwgY291bGQgeW91IGhl bHAgbWU/DQoNCnRoZSBzdHJ1Y3Qgb2YgbGlzdCBpbiB0aGUgc2xpZGluZyB3aW5kb3cgIChkZWNv bXByZXNzIHNpZGUgb3IgY29tcHJlc3Mgc2lkZSkgaW5jbHVkZSB0aGUgaXRlbXMgb3Igbm90Pw0K SXMgaXQgb25seSBpbmNsdWRlIGluZGV4PyBub3QgaXRlbT8gb3IgaXQgaXMgaW5jbHVkZSBib3Ro IGluZGV4IGFuZCBpdGVtPyBUaGFua3MhDQoNCg0KCQkJCWNoZW54aW9uZ2d1aQ0KCQkJCTIwMDYv NS85DQoJ --===============0671291551== 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 --===============0671291551==-- From rohc-bounces@ietf.org Fri May 12 05:46:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUDb-0002Dt-9f; Fri, 12 May 2006 05:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUDZ-0002Do-WF for rohc@ietf.org; Fri, 12 May 2006 05:45:54 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUDY-0000CV-ND for rohc@ietf.org; Fri, 12 May 2006 05:45:53 -0400 Received: by fox.iptel.org (Postfix, from userid 510) id 6308B890804; Fri, 12 May 2006 11:45:16 +0200 (CEST) Date: Fri, 12 May 2006 11:45:16 +0200 From: Cristian Constantin To: rohc@ietf.org Message-ID: <20060512094516.GB15744@fox.iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [rohc] sample udvm bytecodes in the user 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: , Errors-To: rohc-bounces@ietf.org hi! pls refer to http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-user-guide-04.txt section: 4.1.4 DEFLATE (the other sample bytecodes have the same behaviour described by 1. and 2. below some questions about it: 1. what's the trick behind outputting the decompressed bytes _as soon as_ they were decompressed (instead of otuputting when either the whole message was decompressed or you'd overwite some previous decompressed bytes inside your udvm memory) 2. why would such a bytecode always save itself? (like this one does at END-MESSAGE). if it was accessed through a state it does not make much sense to save itself again, does it? thanks! bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 12 05:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUOR-00028j-0F; Fri, 12 May 2006 05:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUOP-00028e-L4 for rohc@ietf.org; Fri, 12 May 2006 05:57:05 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUON-0000ke-48 for rohc@ietf.org; Fri, 12 May 2006 05:57:05 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4C9uVrM002110; Fri, 12 May 2006 10:56:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] sample udvm bytecodes in the user guide Date: Fri, 12 May 2006 10:56:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] sample udvm bytecodes in the user guide Thread-Index: AcZ1qR26PvusTqYgTACARUsbg2HFHgAAITG4 References: <20060512094516.GB15744@fox.iptel.org> From: "West, Mark" To: "Cristian Constantin" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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="===============0858716185==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============0858716185== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C675AA.5B7FB17B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C675AA.5B7FB17B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cristian, Not forgetting that the user's guide code examples are just that -- = examples to show how the fundamentals of different decompression = algorithms could be implemented in a UDVM... =20 1. it's easier! Turning the question around: why *wouldn't* you output = decompressed bytes as soon as you had them? (As opposed to (a) checking = that the message will fit in the decompression buffer; or (b) handling = the over-write case explicitly.) 2. it's easier (at least, for a simple example) than adding the bytecode = necessary to do separate storage of code and data. In general, of = course, it is more efficient to save bytecode separately; this is not = shown in the example, though. How to do it is left as an exercise for = the reader :-) Cheers, Mark. -----Original Message----- From: Cristian Constantin [mailto:cristian.constantin@iptel.org] Sent: Fri 5/12/2006 10:45 AM To: rohc@ietf.org Subject: [rohc] sample udvm bytecodes in the user guide =20 hi! pls refer to=20 http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-user-guide-04= .txt section: 4.1.4 DEFLATE (the other sample bytecodes have the same behaviour described by 1. and 2. below some questions about it: 1. what's the trick behind outputting the decompressed bytes _as soon as_ they were decompressed (instead of otuputting when either the whole message was decompressed or you'd overwite some previous decompressed bytes inside your udvm memory) 2. why would such a bytecode always save itself? (like this one does at END-MESSAGE). if it was accessed through a state it does not make much sense to save itself again, does it? thanks! bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------_=_NextPart_001_01C675AA.5B7FB17B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] sample udvm bytecodes in the user guide

Cristian,

Not forgetting that the user's guide code examples are just that -- = examples to show how the fundamentals of different decompression = algorithms could be implemented in a UDVM... 

1. it's easier!  Turning the question around: why *wouldn't* you = output decompressed bytes as soon as you had them?  (As opposed to = (a) checking that the message will fit in the decompression buffer; or = (b) handling the over-write case explicitly.)

2. it's easier (at least, for a simple example) than adding the bytecode = necessary to do separate storage of code and data.  In general, of = course, it is more efficient to save bytecode separately; this is not = shown in the example, though.  How to do it is left as an exercise = for the reader :-)

Cheers,

Mark.


-----Original Message-----
From: Cristian Constantin [mailto:cristian.constantin@= iptel.org]
Sent: Fri 5/12/2006 10:45 AM
To: rohc@ietf.org
Subject: [rohc] sample udvm bytecodes in the user guide

hi!

pls refer to
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp= -user-guide-04.txt

section: 4.1.4  DEFLATE (the other sample bytecodes have the = same
behaviour described by 1. and 2. below

some questions about it:

1. what's the trick behind outputting the decompressed bytes _as = soon
as_ they were decompressed (instead of otuputting when either the = whole
message was decompressed or you'd overwite some previous = decompressed
bytes inside your udvm memory)

2. why would such a bytecode always save itself? (like this one does = at
END-MESSAGE). if it was accessed through a state it does not make = much
sense to save itself again, does it?

thanks!
bye now!
cristian

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

------_=_NextPart_001_01C675AA.5B7FB17B-- --===============0858716185== 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 --===============0858716185==-- From rohc-bounces@ietf.org Fri May 12 06:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUZR-0004Ck-40; Fri, 12 May 2006 06:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUZQ-0004Cf-Dt for rohc@ietf.org; Fri, 12 May 2006 06:08:28 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUZP-00013u-4t for rohc@ietf.org; Fri, 12 May 2006 06:08:28 -0400 Received: by fox.iptel.org (Postfix, from userid 510) id 63FA78908B9; Fri, 12 May 2006 12:07:45 +0200 (CEST) Date: Fri, 12 May 2006 12:07:45 +0200 From: Cristian Constantin To: "West, Mark" Subject: Re: [rohc] sample udvm bytecodes in the user guide Message-ID: <20060512100745.GC15744@fox.iptel.org> References: <20060512094516.GB15744@fox.iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: rohc-bounces@ietf.org On Fri, May 12, 2006 at 10:56:36AM +0100, West, Mark wrote: > > Cristian, > > Not forgetting that the user's guide code examples are just that -- examples to show how the fundamentals of different decompression algorithms could be implemented in a UDVM... > > 1. it's easier! Turning the question around: why *wouldn't* you output decompressed bytes as soon as you had them? (As opposed to (a) checking that the message will fit in the decompression buffer; or (b) handling the over-write case explicitly.) cristian: bec. for example running memmove, memcpy or whatever function you have behind that output for 500 times say (sometimes for 1 byte!!) is slower than having something that runs only once, twice per bytecode run. > > 2. it's easier (at least, for a simple example) than adding the bytecode necessary to do separate storage of code and data. In general, of course, it is more efficient to save bytecode separately; this is not shown in the example, though. How to do it is left as an exercise for the reader :-) cristian: o.k. I agree. now, suppose that over 50% of the phones (devices) which will use sigcomp will use the sample from the user guide (maybe a little bit tweaked). the P-CSCF software has to _run_ that pretty fast; but any optimization you'd do is useless when such a bytecode is saving itself 100 times per second say... thanks! bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 12 06:21:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUlh-0002XO-5L; Fri, 12 May 2006 06:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUlf-0002Py-LH for rohc@ietf.org; Fri, 12 May 2006 06:21:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUlf-0001ct-2W for rohc@ietf.org; Fri, 12 May 2006 06:21:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4CAKoA3006270; Fri, 12 May 2006 11:21:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] sample udvm bytecodes in the user guide Date: Fri, 12 May 2006 11:20:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] sample udvm bytecodes in the user guide Thread-Index: AcZ1rBALKZuSVngNSoWVC0c/ucq36QAAHQPD References: <20060512094516.GB15744@fox.iptel.org> <20060512100745.GC15744@fox.iptel.org> From: "West, Mark" To: "Cristian Constantin" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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="===============2129879110==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============2129879110== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C675AD.C232AB49" This is a multi-part message in MIME format. ------_=_NextPart_001_01C675AD.C232AB49 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hmmmm... Surely you should implement your 'output' function based on its expected = usage patterns, rather than the other way around..? Also, the trade-off = between bytecode size, complexity, and run-time is not necessarily = straightforward. With regard to your second point, I can understand your concern. = However, I don't see how you can legislate for bad implementations. = (And any implementation that just uses vanilla code from the user's = guide is going to be pretty poor, frankly.) In terms of this specific = issue, I wouldn't have thought that the differential cost of hashing = code + data, as opposed to just data is too big. The bigger cost is = likely to be on compression efficiency... Cheers, Mark. -----Original Message----- From: Cristian Constantin [mailto:cristian.constantin@iptel.org] Sent: Fri 5/12/2006 11:07 AM To: West, Mark Cc: rohc@ietf.org Subject: Re: [rohc] sample udvm bytecodes in the user guide =20 On Fri, May 12, 2006 at 10:56:36AM +0100, West, Mark wrote: >=20 > Cristian, >=20 > Not forgetting that the user's guide code examples are just that -- = examples to show how the fundamentals of different decompression = algorithms could be implemented in a UDVM... =20 >=20 > 1. it's easier! Turning the question around: why *wouldn't* you = output decompressed bytes as soon as you had them? (As opposed to (a) = checking that the message will fit in the decompression buffer; or (b) = handling the over-write case explicitly.) cristian: bec. for example running memmove, memcpy or whatever function you have behind that output for 500 times say (sometimes for 1 byte!!) is slower than having something that runs only once, twice per bytecode run. >=20 > 2. it's easier (at least, for a simple example) than adding the = bytecode necessary to do separate storage of code and data. In general, = of course, it is more efficient to save bytecode separately; this is not = shown in the example, though. How to do it is left as an exercise for = the reader :-) cristian: o.k. I agree. now, suppose that over 50% of the phones = (devices) which will use sigcomp will use the sample from the user guide (maybe a little bit tweaked). the P-CSCF software has to _run_ that pretty fast; but any optimization you'd do is useless when such a bytecode is saving itself 100 times per second say... thanks! bye now! cristian ------_=_NextPart_001_01C675AD.C232AB49 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] sample udvm bytecodes in the user guide

Hmmmm...

Surely you should implement your 'output' function based on its expected = usage patterns, rather than the other way around..?  Also, the = trade-off between bytecode size, complexity, and run-time is not = necessarily straightforward.

With regard to your second point, I can understand your concern.  = However, I don't see how you can legislate for bad = implementations.  (And any implementation that just uses vanilla = code from the user's guide is going to be pretty poor, frankly.)  = In terms of this specific issue, I wouldn't have thought that the = differential cost of hashing code + data, as opposed to just data is too = big.  The bigger cost is likely to be on compression = efficiency...

Cheers,

Mark.



-----Original Message-----
From: Cristian Constantin [mailto:cristian.constantin@= iptel.org]
Sent: Fri 5/12/2006 11:07 AM
To: West, Mark
Cc: rohc@ietf.org
Subject: Re: [rohc] sample udvm bytecodes in the user guide

On Fri, May 12, 2006 at 10:56:36AM +0100, West, Mark wrote:
>
> Cristian,
>
> Not forgetting that the user's guide code examples are just that -- = examples to show how the fundamentals of different decompression = algorithms could be implemented in a UDVM... 
>
> 1. it's easier!  Turning the question around: why *wouldn't* = you output decompressed bytes as soon as you had them?  (As opposed = to (a) checking that the message will fit in the decompression buffer; = or (b) handling the over-write case explicitly.)

cristian: bec. for example running memmove, memcpy or whatever = function
you have behind that output for 500 times say (sometimes for 1 = byte!!)
is slower than having something that runs only once, twice per = bytecode
run.

>
> 2. it's easier (at least, for a simple example) than adding the = bytecode necessary to do separate storage of code and data.  In = general, of course, it is more efficient to save bytecode separately; = this is not shown in the example, though.  How to do it is left as = an exercise for the reader :-)

cristian: o.k. I agree. now, suppose that over 50% of the phones = (devices)
which will use sigcomp will use the sample from the user guide (maybe = a
little bit tweaked). the P-CSCF software has to _run_ that pretty = fast;
but any optimization you'd do is useless when such a bytecode is = saving
itself 100 times per second say...

thanks!
bye now!
cristian

------_=_NextPart_001_01C675AD.C232AB49-- --===============2129879110== 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 --===============2129879110==-- From rohc-bounces@ietf.org Fri May 12 07:27:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVoG-0000kD-Tc; Fri, 12 May 2006 07:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVoF-0000k3-FQ for rohc@ietf.org; Fri, 12 May 2006 07:27:51 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeVoE-0005DS-0y for rohc@ietf.org; Fri, 12 May 2006 07:27:51 -0400 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k4CBRjHN007540; Fri, 12 May 2006 13:27:45 +0200 (CEST) In-Reply-To: <20060512100745.GC15744@fox.iptel.org> References: <20060512094516.GB15744@fox.iptel.org> <20060512100745.GC15744@fox.iptel.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Carsten Bormann Subject: Re: [rohc] sample udvm bytecodes in the user guide Date: Fri, 12 May 2006 13:27:45 +0200 To: Cristian Constantin X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "West, Mark" , Carsten Bormann , 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: , Errors-To: rohc-bounces@ietf.org Interesting discussion. Mark has mostly answered it, but let my add my 0.02=80: > cristian: bec. for example running memmove, memcpy or whatever =20 > function > you have behind that output for 500 times say (sometimes for 1 byte!!) > is slower than having something that runs only once, twice per =20 > bytecode > run. I would expect much of the bytecode (which the sender gets to choose) =20= would be optimized for size, not for speed. The sender has no idea what performance characteristics the =20 receiver's UDVM will have, so it would have a hard time doing the =20 latter. For an industrial strength UDVM, I'd make sure output in small pieces =20= is implemented efficiently. > cristian: o.k. I agree. now, suppose that over 50% of the phones =20 > (devices) > which will use sigcomp will use the sample from the user guide =20 > (maybe a > little bit tweaked). the P-CSCF software has to _run_ that pretty =20 > fast; > but any optimization you'd do is useless when such a bytecode is =20 > saving > itself 100 times per second say... Apart from the fact that, as Mark said, writing good bytecode is a =20 quality of implementation issue on the sender's side; if you actually optimize common cases at the receiver: There may be =20 ways to carry over optimization in a save/load pair just the same way =20= you would carry them in on a state load only. When we developed RFC 3320, our unsubstantiated hunch was that =20 decompression effort times UDVM slowdown factor would be about the =20 same as compression effort (which is "native", i.e., no slowdown by =20 UDVM interpretation), or, in other words, that the UDVM =20 interpretation overhead would be canceled out by the much simpler =20 work a decompressor has to do compared to a compressor. Were we wrong? Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 12 07:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVqn-0002Xn-5m; Fri, 12 May 2006 07:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVqm-0002Xe-5c for rohc@ietf.org; Fri, 12 May 2006 07:30:28 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeVql-0005M3-P5 for rohc@ietf.org; Fri, 12 May 2006 07:30:28 -0400 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k4CBUOJr008939; Fri, 12 May 2006 13:30:24 +0200 (CEST) In-Reply-To: References: <20060512094516.GB15744@fox.iptel.org> <20060512100745.GC15744@fox.iptel.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] sample udvm bytecodes in the user guide Date: Fri, 12 May 2006 13:30:23 +0200 To: Carsten Bormann X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "West, Mark" , rohc@ietf.org, Cristian Constantin 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: , Errors-To: rohc-bounces@ietf.org On May 12 2006, at 13:27 , Carsten Bormann wrote: > writing good bytecode is a quality of implementation issue on the > sender's side; ...and, I should add, there is nothing that stops senders from suddenly colluding to max out on cycles_per_bit; you better dimension your system to be able to cope with that. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 17 04:38:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHY0-0002d5-1h; Wed, 17 May 2006 04:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHXx-0002T0-VX; Wed, 17 May 2006 04:38:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgHXx-0000eT-8U; Wed, 17 May 2006 04:38:21 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D43154F0001; Wed, 17 May 2006 10:37:18 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 10:37:18 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 10:37:18 +0200 Message-ID: <446AE0BD.4020805@ericsson.com> Date: Wed, 17 May 2006 10:37:17 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: IETF AVT WG Subject: Re: [rohc] Fwd: Working group last call: draft-ietf-avt-hc-over-mpls-protocol-05.txt References: <28A58523-F3F5-483E-9763-9E2D5329914F@csperkins.org> <88B272E0-B615-46C9-B608-6AC19B11189A@csperkins.org> In-Reply-To: <88B272E0-B615-46C9-B608-6AC19B11189A@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 08:37:18.0057 (UTC) FILETIME=[1B36E590:01C6798D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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: , Errors-To: rohc-bounces@ietf.org Hi, As your AD I would really appreciate if someone really would review this document and be willing to state that they have reviewed it. We need to ensure that cross WG reviews do work. Cheers Magnus Colin Perkins wrote: > Folks, > > The following working group last call has just been issued in AVT, but > overlaps with the MPLS, ROHC, and PWE3 working groups. We would be > grateful for review from those working groups: please send any comments > on the draft to the mailing list. > > Thanks, > Colin (AVT co-chair) > > > > > Begin forwarded message: >> From: Colin Perkins >> Date: 4 May 2006 17:06:19 BDT >> To: IETF AVT WG >> Subject: Working group last call: >> draft-ietf-avt-hc-over-mpls-protocol-05.txt >> >> This is to announce a working group last call on the Protocol >> Extensions for Header Compression over MPLS >> . Please send any final >> comments on this draft to the avt@ietf.org mailing list by 22nd May >> 2006. If no issues are raised by that time, we will request the IESG >> consider this for publication as a proposed standard RFC. >> >> Colin >> >> >> >> On 3 May 2006, at 20:50, Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Audio/Video Transport Working Group >>> of the IETF. >>> >>> Title : Protocol Extensions for Header Compression over MPLS >>> Author(s) : J. Ash, et al. >>> Filename : draft-ietf-avt-hc-over-mpls-protocol-05.txt >>> Pages : 30 >>> Date : 2006-5-3 >>> >>> VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS >>> labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an >>> MPLS VPN, the packet header is typically 48 bytes, while the voice >>> payload is often no more than 30 bytes, for example. Header >>> compression can significantly reduce the overhead through various >>> compression mechanisms. MPLS is used to route header-compressed (HC) >>> packets over an MPLS LSP without compression/decompression cycles at >>> each router. Such an HC over MPLS capability increases the bandwidth >>> efficiency as well as processing scalability of the maximum number of >>> simultaneous compressed flows that use HC at each router. MPLS >>> pseudowires are used to transport the HC context and other control >>> messages between the ingress and egress MPLS label switched router >>> (LSR). Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to >>> determine the context. Each HC scheme operates over a single >>> pseudowire instance very much like it would over a single >>> point-to-point link. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls-protocol-05.txt >>> > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 17 10:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNM6-0002dJ-45; Wed, 17 May 2006 10:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNM4-0002dE-VD for rohc@ietf.org; Wed, 17 May 2006 10:50:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMSQ-0001wy-Lu for rohc@ietf.org; Wed, 17 May 2006 09:52:58 -0400 Received: from fox.iptel.org ([195.37.77.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgMCX-00057F-98 for rohc@ietf.org; Wed, 17 May 2006 09:36:40 -0400 Received: by fox.iptel.org (Postfix, from userid 510) id 093CE89136A; Wed, 17 May 2006 15:35:51 +0200 (CEST) Date: Wed, 17 May 2006 15:35:51 +0200 From: Cristian Constantin To: Carsten Bormann Subject: Re: [rohc] sample udvm bytecodes in the user guide Message-ID: <20060517133551.GB16081@fox.iptel.org> References: <20060512094516.GB15744@fox.iptel.org> <20060512100745.GC15744@fox.iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: -2.0 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "West, Mark" , 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: , Errors-To: rohc-bounces@ietf.org On Fri, May 12, 2006 at 01:27:45PM +0200, Carsten Bormann wrote: > Interesting discussion. > Mark has mostly answered it, but let my add my 0.02?: > > >cristian: bec. for example running memmove, memcpy or whatever > >function > >you have behind that output for 500 times say (sometimes for 1 byte!!) > >is slower than having something that runs only once, twice per > >bytecode > >run. > > I would expect much of the bytecode (which the sender gets to choose) > would be optimized for size, not for speed. > The sender has no idea what performance characteristics the > receiver's UDVM will have, so it would have a hard time doing the > latter. > For an industrial strength UDVM, I'd make sure output in small pieces > is implemented efficiently. > > >cristian: o.k. I agree. now, suppose that over 50% of the phones > >(devices) > >which will use sigcomp will use the sample from the user guide > >(maybe a > >little bit tweaked). the P-CSCF software has to _run_ that pretty > >fast; > >but any optimization you'd do is useless when such a bytecode is > >saving > >itself 100 times per second say... > > Apart from the fact that, as Mark said, writing good bytecode is a > quality of implementation issue on the sender's side; > if you actually optimize common cases at the receiver: There may be > ways to carry over optimization in a save/load pair just the same way > you would carry them in on a state load only. > > When we developed RFC 3320, our unsubstantiated hunch was that > decompression effort times UDVM slowdown factor would be about the > same as compression effort (which is "native", i.e., no slowdown by > UDVM interpretation), or, in other words, that the UDVM > interpretation overhead would be canceled out by the much simpler > work a decompressor has to do compared to a compressor. > Were we wrong? cristian: here is what I can say about this: - on one side you have a compressor optimized for speed for a certain algorithm. it is written in C and you compile it for the target processor with a good compiler which is able to generate fast code. so, it is the human optimization + the automatic one performed by the compiler. they really sum up. (one very important point here is that the compiler "understands" the C code and uses several tricks to generate machine code which runs fast) - on the other side, in the worst case you have: o an interpreter o non-optimized bytecode interpreted by the interpretor. say you compile the interpretor with the same C compiler for the same architecture; main difference is that the optimizations performed by the compiler on the interpretor code is not helping as much as the one done _directly_ on the code as in the case of the compressor. (in fact the compiler has no idea what this interpretor code does, so it is normal...) that is why I think that comparing the speed of the two is at least tricky. bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 17 12:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOgB-0005Ic-9q; Wed, 17 May 2006 12:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOg8-0005IP-VR; Wed, 17 May 2006 12:15:16 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOg7-0000wk-0q; Wed, 17 May 2006 12:15:16 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2D52F4F0022; Wed, 17 May 2006 18:15:10 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 18:15:09 +0200 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 18:15:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Fwd: Working group lastcall: draft-ietf-avt-hc-over-mpls-protocol-05.txt Date: Wed, 17 May 2006 18:15:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Fwd: Working group lastcall: draft-ietf-avt-hc-over-mpls-protocol-05.txt Thread-Index: AcZ5jN6z5Ik5Th0sSTOMNf70X47vawAHnZBg From: "Kristofer Sandlund \(LU/EAB\)" To: "IETF AVT WG" X-OriginalArrivalTime: 17 May 2006 16:15:09.0775 (UTC) FILETIME=[11A265F0:01C679CD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: "Magnus Westerlund \(KI/EAB\)" , 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: , Errors-To: rohc-bounces@ietf.org Hi AVT! (keeping ROHC in the cc) As per Magnus request, I've done a review of this document from a header = compression perspective (but due to time constraints, I've been pretty = brief and I skipped section 6 altogether, so...). Generally, I think the document is well written and seems to solve the = problem it sets out to do. I have one technical issue with the document = which I think either needs to be clarified or maybe "fixed". Other than that, I just have some comments of the editorial kind. Technical issue: --- The document specifies that a PW should, when it is hc-enabled, ONLY = send compressed packets. In most cases this is fine, but I wonder how = this will work in the case of RFC2507 TCP compression. All the HC schemes used here are built so that if an non-compressible = packet is seen, it should just be sent uncompressed. In the case of ROHC = (and *CRTP), the uncompressible packets are usually such that they are = not expected to be seen at all (IPv4 options etc). The only packet = "normal" packets that are non-compressible is probably IP fragments, and = that's not a big issue. But for IPHC's TCP compression, the HC is built so that non-compressible = packets include packets where SYN or FIN is set, and you _will_ see = those for every TCP flow. When this compression is used in the MPLS = encapsulation, every IPHC-TCP compression instance will require that an = PW for uncompressed traffic is also set up to even manage any TCP = compression. I don't know if the intention of this document is that an uncompressed = PW should always be present, in that case the issue described above = might be a non-issue, but it might be nice to add some short text = describing that IPHC TCP compression will always require the use of an = uncompressed PW in addition to the HC PW it is assigned to (are there = any mapping problems with that?). If the intention is that such uncompressed PWs will not be setup in the = "normal case", then it seems like using IPHC for TCP compression will = either have to: - Specify a way to send uncompressed packets in the same PW as the = compressed ones. - Expicitly set up an uncompressed PW every time the TCP_SPACE is = negotiated to a non-zero value. Either way, some text is needed for this. By the way, another way that this kind of issue can occur is if = MAX_HEADER is configured lower than the longest header chain in which = case compression might not be possible in some cases. Editorial comments: --- - There seems to be a few formatting problems(such as the footer on page = 6), but I guess the RFC editor will fix those.... - There are a lot of abbreviations used in the Abstract, and according = to http://www.ietf.org/ietf/1id-guidelines.html, those should be spelled = out. - In section 2 (Contributors), the following is stated: Besides the editors, the following people contributed to the document: And then the editors are listed. It seems a bit redundant to list the = same addresses both here and in "Authors' addresses" in the document. - Section 4: In the example scenario, HC therefore takes place between R1 and = R4, and the MPLS LSP transports data/compressed-header/MPLS-labels instead of data/RTP/UDP/IP/MPLS-labels, saving 36 octets per = packet in the /RTP/UDP/IP/ header. I don't think you should quantify to "36 bytes", since that is quite = dependent on scheme used (and also you haven't specified if this is IPv4 = or IPv6, which of course has an impact on that figure). Maybe write = something like "often saving more than 90% of the RTP/UDP/IP overhead" - section 4, page 8, the term "PVC" is not defined in terminology - section 5, page 11 Multiple PWs SHOULD be established in case different QoS = requirements are needed for different compressed streams. The QoS received by = the flow would be determined by the EXP bit marking in the PW label. Normally, all RTP packets would get the same EXP marking, = equivalent to EF treatment in DiffServ. However, the protocol specified in = this I think both "EXP marking" and "EF treatment" either need a definition = or a reference to another document, they seem to jump out of nowhere in = this doc. - section 5.1 Any acceptable method of MPLS label distribution MAY be used for distributing the MPLS tunnel label. To assign and distribute the = PW What is an "acceptable method"? Define or re-phrase. - section 5.1 a forward equivalence class (FEC) object, a label object, and FEC is already defined in terminology, so no need to spell it out = here. - Section 5.2 There are a lot of MUSTs/MAYs in this section and (at least from a = quick reading) some of them seem to say the same thing, such as: If HC scheme parameters are signaled, the Interface Parameters Sub-TLV MUST be used on any unidirectional legs of a PW that will carry HC = traffic. and The Interface Parameters Sub-TLV [IANA, RFC4447] MUST be used to signal HC channel setup and specify HC parameters. Do these two describe _different_ requirements? If not, maybe one of = them could either be removed or it could be written to avoid 2119 = language. I'm not keen on having the same requirement listed twice (_if_ = that is the case here, there might be some subtle difference that I'm = failing to see). There might be others like these in 5.2 that are overlapping, so maybe a = thorough check by of 2119 language in this section could be useful. - Section 5.2.4 In RFC 2509 it was not possible to negotiate only TCP HC or only Maybe you need to add an informative reference to 2509 since you = mention it? - Section 5.4 Be consistent and don't mix "misordering" and "reordering", just write = "reordering". - Section 5.4 CRTP is viewed as having risks for a number PW environments due to misordering and loss, although commercial issues lead to its choice. I don't understand this sentence, what do you mean by "lead to its = choice"? Is the intension to say "the inclusion of CRTP into this = specification was based on commercial reasons"? And if you're going to write "commercial issues" (or reasons) then = maybe you should describe those (but I prefer to re-phrase that to = something else instead) - The reference section might need to be verified a bit, for example = [ROHC-REORDER] is now an RFC (RFC4224). There's also some control symbol = (=3D20) in one of the references, so it might be good to review all the = references again to make sure they are correct. /Kristofer Sandlund Magnus Westerlund wrote: > Hi, >=20 > As your AD I would really appreciate if someone really would review > this document and be willing to state that they have reviewed it. We > need to ensure that cross WG reviews do work. >=20 > Cheers >=20 > Magnus >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu May 18 01:59:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgbXa-00076z-9J; Thu, 18 May 2006 01:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgbXY-00076u-W6 for rohc@ietf.org; Thu, 18 May 2006 01:59:16 -0400 Received: from [203.101.112.21] (helo=mail2.sonimtech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgbXX-0007or-3Z for rohc@ietf.org; Thu, 18 May 2006 01:59:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] freely available sip server/client to test sigcomp? Date: Thu, 18 May 2006 11:29:11 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] freely available sip server/client to test sigcomp? Thread-Index: AcZyoh6xj9wS5xaoQkyw+Kwxksb35AHniOyQ From: "Vishal Sudan" To: "Sarvamangala" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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="===============1852561189==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1852561189== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67A40.2F7BB590" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67A40.2F7BB590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You can use Ethereal 10.14 for interop testing.It supports Sigcomp too. =20 Thanks and Regards, Vishal Sudan -----Original Message----- From: Sarvamangala [mailto:sarvamangala.dr@globaledgesoft.com] Sent: Monday, May 08, 2006 6:48 PM To: rohc@ietf.org Subject: [rohc] freely available sip server/client to test sigcomp? Hi=20 =20 I would like to know if there any freely available sip server or client = supporting sigcomp.=20 This is needed for interoperabilty test. =20 Regards, Sarvamangala =20 ------_=_NextPart_001_01C67A40.2F7BB590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You can use Ethereal 10.14 for interop = testing.It=20 supports Sigcomp too.
 
Thanks and=20 Regards,
Vishal=20 Sudan
-----Original Message-----
From: Sarvamangala=20 [mailto:sarvamangala.dr@globaledgesoft.com]
Sent: Monday, = May 08,=20 2006 6:48 PM
To: rohc@ietf.org
Subject: [rohc] = freely=20 available sip server/client to test sigcomp?

Hi
 
I would like to know if there = any freely=20 available sip server or client supporting sigcomp.
This is needed for interoperabilty=20 test.
 
Regards,
Sarvamangala
 
------_=_NextPart_001_01C67A40.2F7BB590-- --===============1852561189== 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 --===============1852561189==-- From rohc-bounces@ietf.org Fri May 19 04:34:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0Rd-0005lR-Qh; Fri, 19 May 2006 04:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0Rc-0005kg-NU for rohc@ietf.org; Fri, 19 May 2006 04:34:48 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh0RX-00051z-Ll for rohc@ietf.org; Fri, 19 May 2006 04:34:48 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZI006HR87HCZ@szxga03-in.huawei.com> for rohc@ietf.org; Fri, 19 May 2006 16:42:54 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZI0046E87HNV@szxga03-in.huawei.com> for rohc@ietf.org; Fri, 19 May 2006 16:42:53 +0800 (CST) Received: from [127.0.0.1] ([10.18.5.200]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZI00B6N8O28T@szxml01-in.huawei.com> for rohc@ietf.org; Fri, 19 May 2006 16:52:52 +0800 (CST) Date: Fri, 19 May 2006 14:04:16 +0530 From: Srinivas R Thota To: rohc@ietf.org Message-id: <446D8308.1030508@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [rohc] Sigcomp Record Marking 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: , Errors-To: rohc-bounces@ietf.org Why does Sigcomp use record marking for finding the compressed message delimiter, can't this be done by having the length of Sigcomp message in Sigcomp message header ? Regards, Srinivas R Thota _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 19 04:43:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0aQ-0001Fl-Ts; Fri, 19 May 2006 04:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0aP-0001BI-PJ for rohc@ietf.org; Fri, 19 May 2006 04:43:53 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh0aP-0005M0-BK for rohc@ietf.org; Fri, 19 May 2006 04:43:53 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4J8hLAc006423; Fri, 19 May 2006 09:43:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] Sigcomp Record Marking Date: Fri, 19 May 2006 09:40:50 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Sigcomp Record Marking Thread-Index: AcZ7H0NPPsio4/ViTdCF70qmzu508gAAKsiL References: <446D8308.1030508@huawei.com> From: "West, Mark" To: "Srinivas R Thota" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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="===============1080591898==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1080591898== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67B20.48A6B7D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67B20.48A6B7D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Srinivas, SigComp has to run over UDP and TCP. For UDP there's an implicit length = (derived from the payload length). For TCP there has to be explicit = length indication (either, as you suggest, by including the length in = the header; or by marking records). We went for record marking, so as not to have different versions of the = header. Cheers, Mark. -----Original Message----- From: Srinivas R Thota [mailto:srinivas_thota@huawei.com] Sent: Fri 5/19/2006 9:34 AM To: rohc@ietf.org Subject: [rohc] Sigcomp Record Marking =20 Why does Sigcomp use record marking for finding the compressed message=20 delimiter, can't this be done by having the length of Sigcomp message in Sigcomp=20 message header ? Regards, Srinivas R Thota _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------_=_NextPart_001_01C67B20.48A6B7D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] Sigcomp Record Marking

Srinivas,

SigComp has to run over UDP and TCP.  For UDP there's an implicit = length (derived from the payload length).  For TCP there has to be = explicit length indication (either, as you suggest, by including the = length in the header; or by marking records).

We went for record marking, so as not to have different versions of the = header.

Cheers,

Mark.


-----Original Message-----
From: Srinivas R Thota [mailto:srinivas_thota@huawei.co= m]
Sent: Fri 5/19/2006 9:34 AM
To: rohc@ietf.org
Subject: [rohc] Sigcomp Record Marking

Why does Sigcomp use record marking for finding the compressed = message
delimiter,
can't this be done by having the length of Sigcomp message in = Sigcomp
message header ?

Regards,
Srinivas R Thota


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

------_=_NextPart_001_01C67B20.48A6B7D6-- --===============1080591898== 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 --===============1080591898==-- From rohc-bounces@ietf.org Fri May 19 09:51:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5Nd-0005j4-4B; Fri, 19 May 2006 09:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5Lu-00050C-AR; Fri, 19 May 2006 09:49:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh5Lr-0001C1-Ke; Fri, 19 May 2006 09:49:14 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C2CA64F0002; Fri, 19 May 2006 15:49:04 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 15:49:04 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 15:49:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 May 2006 15:49:02 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502E2804A@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Re: draft-ietf-avt-hc-over-mpls-protocol-05.txt Thread-Index: AcZ6cO01rO+PL0wGQWCDLtm5kGkJbAA2PlGA From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Andrew G. Malis" , "Gray, Eric" X-OriginalArrivalTime: 19 May 2006 13:49:04.0079 (UTC) FILETIME=[FDB2D5F0:01C67B4A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Fri, 19 May 2006 09:50:59 -0400 Cc: "Ash, Gerald R \\\(Jerry\\\)" , rohc@ietf.org, Andy Malis , James Hand , avt@ietf.org, Danny McPherson , Danny McPherson , "PWE3 WG \(E-mail\)" , Stewart Bryant Subject: [rohc] RE: [AVT] Re: draft-ietf-avt-hc-over-mpls-protocol-05.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: , Errors-To: rohc-bounces@ietf.org >> QUESTIONS: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> In number 3 (section 4, under summary of procedures), it says: >>=20 >> "R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to >> send HC scheme control packets and compressed packets to R4/HC,=20 >> with LSP and PW labels."=20 >>=20 >> Do the existing compression schemes universally provide a means >> to ensure that this information is received by the de-compressor >> (i.e. - do they include an ACK for this)? >=20 > I don't know - I'll let one of the HC experts answer that one. I am not sure exactly what the question is about, but... - All HC schemes have the multiplexing mechanism needed to separate "flows", i.e. they have a Context IDentification function. - CID's are usually included in ALL compressed header packets. I do not know what you mean with the ACK question, some schemes can make use of explicit ACKs, while some are simply NACK-based. - All this is about internal HC scheme functioning, I do not see why it is relevant to HC-over-MPLS. I hope this clairified. Otherwise, let me know! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 19 18:32:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhDVn-0001ai-Ua; Fri, 19 May 2006 18:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhDVm-0001aL-20; Fri, 19 May 2006 18:31:58 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FhDVj-0003Da-6g; Fri, 19 May 2006 18:31:58 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-126.messagelabs.com!1148077837!11898080!6 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14803 invoked from network); 19 May 2006 22:31:53 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-126.messagelabs.com with SMTP; 19 May 2006 22:31:53 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE0037BD41; Fri, 19 May 2006 18:31:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] RE: [rohc] Fwd: Working group last call: draft-ietf-avt-hc-over-mpls-protocol-05.txt Date: Fri, 19 May 2006 17:31:52 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7793@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RE: [rohc] Fwd: Working group last call: draft-ietf-avt-hc-over-mpls-protocol-05.txt Thread-Index: AcZ5jN6z5Ik5Th0sSTOMNf70X47vawAHnZBgAGitqTA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Kristofer Sandlund \(LU/EAB\)" , "IETF AVT WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: "Ash, Gerald R \(Jerry\), ALABS" , rohc@ietf.org, "Magnus Westerlund \(KI/EAB\)" 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: , Errors-To: rohc-bounces@ietf.org Hi Kristofer, Many thanks for your thorough review. Please see comments below. Thanks, Regards, Jerry=20 > -----Original Message----- > From: Kristofer Sandlund (LU/EAB)=20 > [mailto:kristofer.sandlund@ericsson.com]=20 > Sent: Wednesday, May 17, 2006 12:15 PM > To: IETF AVT WG > Cc: Magnus Westerlund (KI/EAB); rohc@ietf.org > Subject: [AVT] RE: [rohc] Fwd: Working group last call:=20 > draft-ietf-avt-hc-over-mpls-protocol-05.txt >=20 > Hi AVT! (keeping ROHC in the cc) >=20 > As per Magnus request, I've done a review of this document=20 > from a header compression perspective (but due to time=20 > constraints, I've been pretty brief and I skipped section 6=20 > altogether, so...). >=20 > Generally, I think the document is well written and seems to=20 > solve the problem it sets out to do. I have one technical=20 > issue with the document which I think either needs to be=20 > clarified or maybe "fixed". > Other than that, I just have some comments of the editorial kind. >=20 > Technical issue: > --- > The document specifies that a PW should, when it is=20 > hc-enabled, ONLY send compressed packets. In most cases this=20 > is fine, but I wonder how this will work in the case of=20 > RFC2507 TCP compression. > All the HC schemes used here are built so that if an=20 > non-compressible packet is seen, it should just be sent=20 > uncompressed. In the case of ROHC (and *CRTP), the=20 > uncompressible packets are usually such that they are not=20 > expected to be seen at all (IPv4 options etc). The only=20 > packet "normal" packets that are non-compressible is probably=20 > IP fragments, and that's not a big issue. > But for IPHC's TCP compression, the HC is built so that=20 > non-compressible packets include packets where SYN or FIN is=20 > set, and you _will_ see those for every TCP flow. When this=20 > compression is used in the MPLS encapsulation, every IPHC-TCP=20 > compression instance will require that an PW for uncompressed=20 > traffic is also set up to even manage any TCP compression. >=20 > I don't know if the intention of this document is that an=20 > uncompressed PW should always be present, in that case the=20 > issue described above might be a non-issue, but it might be=20 > nice to add some short text describing that IPHC TCP=20 > compression will always require the use of an uncompressed PW=20 > in addition to the HC PW it is assigned to (are there any=20 > mapping problems with that?). > If the intention is that such uncompressed PWs will not be=20 > setup in the "normal case", then it seems like using IPHC for=20 > TCP compression will either have to: > - Specify a way to send uncompressed packets in the same PW=20 > as the compressed ones. > - Explicitly set up an uncompressed PW every time the=20 > TCP_SPACE is negotiated to a non-zero value. > Either way, some text is needed for this. > > By the way, another way that this kind of issue can occur is=20 > if MAX_HEADER is configured lower than the longest header=20 > chain in which case compression might not be possible in some cases. You raise a valid issue here. The uncompressed packets associated with HC flows (e.g., uncompressed IPHC-TCP packets) can be sent through the same MPLS tunnel along with all other non-HC (non-PW) IP packets. MPLS tunnels can transport many types of packets simultaneously, including non-PW IP packets, layer 3 VPN packets, and PW (e.g., HC flow) packets. We don't see a need to require a separation of uncompressed IP packets associated with HC flows and other uncompressed IP packets. =20 In the draft we've already assumed that there would be a path for uncompressed traffic, and that it would be a compressor decision as to what would or would not go in the HC-PW. We'll make it more explicit that for some types of compression (e.g., IPHC-TCP) a non-compressed path is required. > Editorial comments: > --- > - There seems to be a few formatting problems (such as the=20 > footer on page 6), but I guess the RFC editor will fix those.... >=20 > - There are a lot of abbreviations used in the Abstract, and=20 > according to http://www.ietf.org/ietf/1id-guidelines.html,=20 > those should be spelled out. >=20 > - In section 2 (Contributors), the following is stated: > Besides the editors, the following people contributed to the > document: > And then the editors are listed. It seems a bit redundant=20 > to list the same addresses both here and in "Authors'=20 > addresses" in the document. Agree with all of the above and will fix. =20 > - Section 4: > In the example scenario, HC therefore takes place=20 > between R1 and R4, > and the MPLS LSP transports data/compressed-header/MPLS-labels > instead of data/RTP/UDP/IP/MPLS-labels, saving 36=20 > octets per packet > in the /RTP/UDP/IP/ header. >=20 > I don't think you should quantify to "36 bytes", since that=20 > is quite dependent on scheme used (and also you haven't=20 > specified if this is IPv4 or IPv6, which of course has an=20 > impact on that figure). Maybe write something like "often=20 > saving more than 90% of the RTP/UDP/IP overhead" Good point, the suggested re-wording looks fine. > - section 4, page 8, the term "PVC" is not defined in terminology OK, will define. > - section 5, page 11 > Multiple PWs SHOULD be established in case different=20 > QoS requirements > are needed for different compressed streams. The QoS=20 > received by the > flow would be determined by the EXP bit marking in the PW label. > Normally, all RTP packets would get the same EXP=20 > marking, equivalent > to EF treatment in DiffServ. However, the protocol=20 > specified in this > > I think both "EXP marking" and "EF treatment" either need a=20 > definition or a reference to another document, they seem to=20 > jump out of nowhere in this doc. Agreed, will reference RFC 3246 (EF) and RFC 3270 (EXP marking) here. > - section 5.1 > Any acceptable method of MPLS label distribution MAY be used for > distributing the MPLS tunnel label. To assign and=20 > distribute the PW > What is an "acceptable method"? Define or re-phrase. OK, will reference LDP [RFC 3036), MPLS-TE (RFC 3209), and configuration as 'acceptable methods'. =20 > - section 5.1 > a forward equivalence class (FEC) object, a label object, and > FEC is already defined in terminology, so no need to spell=20 > it out here. OK. =20 > - Section 5.2 > There are a lot of MUSTs/MAYs in this section and (at least=20 > from a quick reading) some of them seem to say the same=20 > thing, such as: > If HC scheme > parameters are signaled, the Interface Parameters=20 > Sub-TLV MUST be > used on any unidirectional legs of a PW that will carry=20 > HC traffic. > and > The Interface Parameters Sub-TLV [IANA, > RFC4447] MUST be used to signal HC channel setup and specify HC > parameters. >=20 > Do these two describe _different_ requirements? If not, maybe=20 > one of them could either be removed or it could be written to=20 > avoid 2119 language. I'm not keen on having the same=20 > requirement listed twice (_if_ that is the case here, there=20 > might be some subtle difference that I'm failing to see). > There might be others like these in 5.2 that are overlapping,=20 > so maybe a thorough check by of 2119 language in this section=20 > could be useful. OK, will check and use 2119 language only once. > - Section 5.2.4 > In RFC 2509 it was not possible to negotiate only TCP HC or only >=20 > Maybe you need to add an informative reference to 2509=20 > since you mention it? OK. =20 > - Section 5.4 > Be consistent and don't mix "misordering" and "reordering",=20 > just write "reordering". OK. > - Section 5.4 > CRTP is viewed as > having risks for a number PW environments due to misordering and > loss, although commercial issues lead to its choice. > I don't understand this sentence, what do you mean by "lead=20 > to its choice"? Is the intension to say "the inclusion of=20 > CRTP into this specification was based on commercial reasons"? > And if you're going to write "commercial issues" (or=20 > reasons) then maybe you should describe those (but I prefer=20 > to re-phrase that to something else instead) We can rephrase to say something like "Although CRTP is viewed as having risks for a number of PW environments due to misordering and loss, it is still the protocol of choice in many cases." > - The reference section might need to be verified a bit, for=20 > example [ROHC-REORDER] is now an RFC (RFC4224). There's also=20 > some control symbol (=3D20) in one of the references, so it=20 > might be good to review all the references again to make sure=20 > they are correct. OK. Thanks again, Jerry >=20 > /Kristofer Sandlund >=20 >=20 > Magnus Westerlund wrote: >=20 > > Hi, > >=20 > > As your AD I would really appreciate if someone really would review > > this document and be willing to state that they have reviewed it. We > > need to ensure that cross WG reviews do work. > >=20 > > Cheers > >=20 > > Magnus > >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 22 06:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi7Wd-000735-7g; Mon, 22 May 2006 06:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi7Wb-000730-No for rohc@ietf.org; Mon, 22 May 2006 06:20:33 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi7WZ-0000Du-TE for rohc@ietf.org; Mon, 22 May 2006 06:20:33 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CC8ADAB for ; Mon, 22 May 2006 12:20:31 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 12:20:30 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 12:20:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 May 2006 12:20:27 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502E28664@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-write of the RTP implementer's guide, a proposal from the authors Thread-Index: AcZ9iVgvmStO8Cs+QaeGqzLOZwTQcA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 22 May 2006 10:20:30.0543 (UTC) FILETIME=[5A4A05F0:01C67D89] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [rohc] Re-write of the RTP implementer's guide, a proposal from the authors 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: , Errors-To: rohc-bounces@ietf.org ROHC RTP folks, We did a WGLC on the ROHC RTP implementer's guide in December, but at that point we were not sure about the target category for this document. Through discussions with the AD, it was decided to target standards track, which made us start thinking of the document in a slightly different way. An updated -18 version was released to introduce RFC2119 language, and a second WGLC was issued on that draft. There were no concrete comments on the -18 version, but we got some more philosophical high-level comments about the draft (see the ROHC list, February 24th) that made us think we should give the draft some more time. So, since then the authors have spent some time on a re-write of the draft. It is not significantly changed, but almost all parts have been touched in some way. The re-write is in general just editorial, not making any formal changes. However, during the process we did find some technical flaws that we have corrected. The draft just submitted, revision -19, is thus a proposal from the authors. The changes from -18 are presented below and this is thus a call for feedback on these changes. If we can agree on these, we will be able to consider -19 current WG consensus. The draft (when announced) will be found at: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-19.txt= Here are the changes made (minor pure edits omitted): * The following line has been added to the first page heading of the draft: TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 The RFC editor will then replace this with: UPDATES: RFC 3095, 3241, 3843, 4019, 4362 * The title has been changed to: RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 * The abstract has been slightly rewritten. * Chapter titles have been slightly changed (removed useless words). * New formalised terminology has been introduced to clearly indicate incorrect or incomplete text in RFC 3095, as well as corrections, invalidations, and additions (see the end of the Introduction and Terminology chapter). This means various sections have also been adjusted to make use of these keywords. * Some texts have been rewritten to be more concise and clear, e.g. redundant text has been removed (see the diff to review these). * Chapter 3 now incorporates everything related to mode transition, also "3.2. Feedback during mode transition"=20 (new section) and "3.3. Packet decoding during mode transition" (previously section 8.7). * Section 3.2. has been added, its content should speak for itself. * In section 4.5., "TS wraparound with scaled timestamp encoding", the TS wraparound algorithm has been invalidated since it is not sufficiently specified to be implemented in an interoperable way, neither is it needed or useful. * Section 5.1., "Generic extension header list" has been removed because RFC 3095 is in no way unclear on this. When we failed to understand why this ever entered the implementer's guide, we started to dig into the mail archive, and tracked down the following question as a possible starting point. http://www1.ietf.org/mail-archive/web/rohc/old-archive/msg03548.html The answer to the question can be easily and clearly found in RFC 3095, therefore we think the section should go away from this document. * The chapter 5 subsection "RTP dynamic chain" has changed title and is now called "5.2. Multiple occurrences of the CC field". * Previous section 5.4., "Compressed lists in UO-1-ID packets" has been merged into section 6.2., "Updating properties of UO-1*". * Chapter 5 now incorporates also "5.8. Compression of AH and GRE sequence numbers" (previously section 8.13). * Chapter 6 now incorporates also "6.3. Context updating properties for IR packets" (previously section 7.3), "6.4. RTP padding field (R-P) in extension 3" (previously section 8.9 "What does "presumed zero if absent" mean on page 88?"), and "6.5. RTP eXtension bit (X) in dynamic part" (new section). * Section 6.5. has been added, its content should speak for itself. * Previous section 8.3., "Extension-3 in UO-1-ID packets" has been merged into section 6.2., "Updating properties of UO-1*". * A new section 8.4., "Multiple occurrences of the M bit" has been added, this was missing but is similar to the CC-case. * The security considerations have been slightly rewritten. * Indentation has been corrected in the appendix. Please review these changes and let us know if there are any disagreements on them, or any questions. BR /L-E =20 ----------------------------------- Lars-Erik Jonsson, M.Sc. Senior Research Engineer Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com /"\ Phone: +46 8 404 29 61 \ / Fax: +46 920 996 21 ASCII Ribbon Campaign X Home: +46 63 355 24 against HTML email & vCards / \ My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 22 15:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGPu-0002UC-BU; Mon, 22 May 2006 15:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGPk-0002SF-6Y; Mon, 22 May 2006 15:50:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiGPi-0000y1-5S; Mon, 22 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4MJo1XO004742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FiGPh-000334-L0; Mon, 22 May 2006 15:50:01 -0400 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, 22 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-19.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: , 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): Corrections and Clarifications to RFC 3095 Author(s) : L. Jonsson, et al. Filename : draft-ietf-rohc-rtp-impl-guide-19.txt Pages : 29 Date : 2006-5-22 RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP, UDP, RTP, and ESP. Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles) are also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-19.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-19.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-19.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-5-22113415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-22113415.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 Tue May 23 12:31:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZnC-0007Ay-2i; Tue, 23 May 2006 12:31:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZnA-0007At-RK for rohc@ietf.org; Tue, 23 May 2006 12:31:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZn1-0006fT-8Q for rohc@ietf.org; Tue, 23 May 2006 12:31:32 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F5E368D for ; Tue, 23 May 2006 18:31:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 18:31:08 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 18:31:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2006 18:31:08 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D054DAFCB@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interpretation intervals for TS encoding Thread-Index: AcZ+hkuBEZdYls4sTIiU3eeM9+1wEQ== From: "Endre Szalai \(IJ/ETH\)" To: X-OriginalArrivalTime: 23 May 2006 16:31:08.0787 (UTC) FILETIME=[4BBA8430:01C67E86] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [rohc] Interpretation intervals for TS encoding 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: , Errors-To: rohc-bounces@ietf.org Hi ROHCers, reading the "Corrections and Clarifications to RFC 3095" (draft-ietf-rohc-rtp-impl-guide-19.txt) document, the last paragraph of section 4.3 is not really clear for me. "Since two different p-values are used, the compressor must take this into account throughout the process of enabling timer-based compression (see section 4.8 of this document). During transition from window-based compression to timer-based compression, it is thus necessary that the compressor keep k large enough to cover both interpretation intervals." When the HC wants to use timer based compression, it will start sending a positive TIME_STRIDE value (after of course a valid CLOCK option is propagated from the HD). If the HD receives such a packet, it will switch to timer based compression immediately. This means, that the HD will use the value for "p" as specified in section 4.5.4 in RFC 3095) when decompressing received TS bits (if any), and not the "p" value for the W-LSB encoding. Why and how the HC should consider the "p" value for W-LSB encoding in this case ? The HC keeps track of all possible references the HD may have, and the HC will simply apply timer based compression with the proper "p" value. Since HD will use the same "p" value (TIME_STRIDE > 0), how could the 2 different interpretation intervals interfere ? Could someone give a clarification on this (maybe an example) ? Thanks, Endre =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=3D=3D=3D=3D=3D Endre Szalai wired > +36 1 437 7796 Software Developer mobile > +36 30 343 7061 Conformance Center fax > +36 1 437 7576 ERICSSON Hungary (ETH) mail > Endre.Szalai@ericsson.com =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=3D=3D=3D=3D=3D =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 23 12:43:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZyG-0001Qc-0d; Tue, 23 May 2006 12:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZyF-0001QW-6Y for rohc@ietf.org; Tue, 23 May 2006 12:42:59 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZy6-0007Df-Nl for rohc@ietf.org; Tue, 23 May 2006 12:42:59 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 924EF4F0001 for ; Tue, 23 May 2006 18:42:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 18:42:48 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 18:42:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2006 18:42:48 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D054DAFD2@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Context(Tsc) Thread-Index: AcZ+h+zKy4crLQx2RIqL6FTGH5xeHQ== From: "Endre Szalai \(IJ/ETH\)" To: X-OriginalArrivalTime: 23 May 2006 16:42:48.0664 (UTC) FILETIME=[ECE34580:01C67E87] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [rohc] Context(Tsc) 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: , Errors-To: rohc-bounces@ietf.org Hi ROHCers, A minor suggestion: Section 4.7 in the "Corrections and Clarifications to RFC 3095" (draft-ietf-rohc-rtp-impl-guide-19.txt) document mentions that: "Context(Tsc) is always 1. If scaling is not desired, the compressor will establish TS_STRIDE =3D 1." Beside that Tsc is not listed in section 6.5.1 and 6.5.2 of RFC 3095; it is completely meaningless to suggest, that Tsc is one of the values that should be kept in the context, since its value is always constant, never updated.=20 Tsc has effect only on the current packet, never on packets after that. I think it would be better to remove the first sentence "Context(Tsc) is always 1." Regards, Endre =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=3D=3D=3D=3D=3D Endre Szalai wired > +36 1 437 7796 Software Developer mobile > +36 30 343 7061 Conformance Center fax > +36 1 437 7576 ERICSSON Hungary (ETH) mail > Endre.Szalai@ericsson.com =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=3D=3D=3D=3D=3D =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 23 12:53:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia8V-0006xn-Jy; Tue, 23 May 2006 12:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia8U-0006pn-3B for rohc@ietf.org; Tue, 23 May 2006 12:53:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fia8S-0007nH-Op for rohc@ietf.org; Tue, 23 May 2006 12:53:34 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3C4334F0001 for ; Tue, 23 May 2006 18:53:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 18:53:31 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 18:53:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2006 18:53:31 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D054DAFD9@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcZ+iWvgKKpwhAmeRdC8QJq0+2Uh1Q== From: "Endre Szalai \(IJ/ETH\)" To: X-OriginalArrivalTime: 23 May 2006 16:53:31.0277 (UTC) FILETIME=[6BEA3BD0:01C67E89] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [rohc] (no subject) 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: , Errors-To: rohc-bounces@ietf.org Hi ROHCers, Section 5.1 of the "Corrections and Clarifications to RFC 3095" (draft-ietf-rohc-rtp-impl-guide-19.txt) document clarifies that the 'Generic CSRC list' field is always at least 1 octet, even if the list is empty. This statement was already present in the previous version of the document, but for IP extension header only. Now it covers CSRC list only. Since the statement is true both for IP extension header lists and for CSRC lists, I suggest to correct the paragraph and its title to cover both cases: 5.1. Generic extension header list and generic CSRC list The 'generic extension header list' and the 'generic CSRC list' fields start with an octet that is always present, so its length is one octet, at least. Regards, Endre =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=3D=3D=3D=3D=3D Endre Szalai wired > +36 1 437 7796 Software Developer mobile > +36 30 343 7061 Conformance Center fax > +36 1 437 7576 ERICSSON Hungary (ETH) mail > Endre.Szalai@ericsson.com =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=3D=3D=3D=3D=3D =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 24 03:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FinyV-0007oW-O8; Wed, 24 May 2006 03:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FinyU-0007oR-Nh for rohc@ietf.org; Wed, 24 May 2006 03:40:10 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FinyK-00087Y-4f for rohc@ietf.org; Wed, 24 May 2006 03:40:10 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 922DFA2D for ; Wed, 24 May 2006 09:39:59 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 09:39:59 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 09:39:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 May 2006 09:39:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SC-FC ping pong Thread-Index: AcZ/BUHaDYaF9QtLSmaKfMpNhxGIVA== From: "Lajos Zaccomer \(IJ/ETH\)" To: X-OriginalArrivalTime: 24 May 2006 07:39:58.0766 (UTC) FILETIME=[4220FCE0:01C67F05] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [rohc] SC-FC ping pong 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: , Errors-To: rohc-bounces@ietf.org Hi RoHCers, Say the decompressor is in state FC, and the compressor wants to update a field in static part (O-mode). Say the OA period is short and all updating IR packets are lost. The subsequent UO-0 packets cannot be successfully decompressed due to the old static field. As a result, the=20 decompressor transits to state SC and probably sends NACK, after some CRC failures (there is no way for the decompressor to find out what went wrong). In this case, it is completely legal for the compressor to send IR-DYN - even though the earlier update of a field in the static part may be a good reason not to do so. On receipt of the IR-DYN, the decompressor happily=20 transits from SC to FC (even though the IR-DYN is also incorrect as the CRC-8 does not protect the original header), but alas, the UO-0 packets would fail again, driving the couple to a neverending story. The decompressor would produce only packets with incorrect header when=20 IR-DYN received and nothing (besides CRC failure) otherwise. I think, the problem is that the specification does not prohibit such a situation. We may call it deadlock, because there is no way to recover. This (maybe simple but still RFC 3095 compliant) compressor would never learn about the failure. I can recommend two alternatives that guarantee recovery: a) Explicitly require compressors to avoid sending IR-DYN in such cases; or b) do not let decompressors to transit from SC to FC after successful decompression of IR-DYN, which would drive it to state SC after some CRC failures and so to send STATIC-NACK. Looking forward to reading your opinion and comments. Best regards, Zacco _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 24 03:40:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Finz5-0008Ai-NB; Wed, 24 May 2006 03:40:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Finz4-0008AO-LR for rohc@ietf.org; Wed, 24 May 2006 03:40:46 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Finz3-0008A7-6C for rohc@ietf.org; Wed, 24 May 2006 03:40:46 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 680A0CC3 for ; Wed, 24 May 2006 09:40:38 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 09:40:37 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 09:40:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 May 2006 09:40:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of RTP P and X bits Thread-Index: AcZ/BVj7TIPeh0dAQaCRpYmJLLk7+Q== From: "Lajos Zaccomer \(IJ/ETH\)" To: X-OriginalArrivalTime: 24 May 2006 07:40:37.0641 (UTC) FILETIME=[594CD790:01C67F05] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [rohc] Update of RTP P and X bits 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: , Errors-To: rohc-bounces@ietf.org Hi RoHCers, The latest Implementers' Guide (version 19) clarified the update of RTP P and X bits in sections 6.4 and 6.5 in a strange way, at least compared to other fields and the significance of these two bits: - if 0, there is no need to send the optional packet part (but may be sent for other reasons) - if 1, the optional packet part containing the P/X bit must be sent This solution is optimized for the case when X =3D 0 and P =3D 0. This = is in contrast with RFC 3095 A.1.4 that says both P and X are application dependent, even though X is expected to be 0 in most cases. If P/X is 1, the optional packet part containing the P/X bit must be included, even though the value is not changed. This means one additional octet in EXT-3 for P bit and one additional octet in RTP dynamic part for X bit. As a compensation, the solution may save one=20 octet in RTP dynamic part for X bit if 0; however, even this is unlikely to happen, as the TS_STRIDE is most probably sent in the establishment. (As the value of P/X is not expected to change during the lifetime of the packet flow, as said in RFC 3095 A.1.4, only the establishment period is of concern.) In case a CID is reused with the same X=3D1 value as of the previous packet flow, it must be updated, even though it is not changed - because of the value 1. Even if X=3D0, the optional part in the RTP dynamic part is probably sent due to TS_STRIDE establishment - unless it is also the same. What is the advantage then? Is P=3D1 and/or X=3D1 really that unlikely = that it is worth deferring from the clean way of updating other fields not function of SN to save one octet per thousands of packets? EXT-3 must be quite common to cope with irregularities, therefore I'm not quite comfortable with the idea to update a field based on its value instead of being changed, as for all other fields not function of SN (except RTP M bit, but that is reasonably explained in RFC 3095 A.1.4). This seems to be additional complexity mainly to send more bytes in some cases. Looking forward to reading your opinion and comments. Best regards, Zacco _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu May 25 09:13:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFdu-0003yX-Kv; Thu, 25 May 2006 09:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFdt-0003yP-Go for rohc@ietf.org; Thu, 25 May 2006 09:12:45 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFdq-0007yf-62 for rohc@ietf.org; Thu, 25 May 2006 09:12:45 -0400 Received: from mailgate.qd.lucent.com (h135-252-34-206.lucent.com [135.252.34.206]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4PDCdWp029953 for ; Thu, 25 May 2006 08:12:40 -0500 (CDT) Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 May 2006 21:11:48 +0800 Received: from [192.11.23.110] ([192.11.23.110]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 May 2006 21:11:48 +0800 Message-ID: <4475AD11.8020001@lucent.com> Date: Thu, 25 May 2006 21:11:45 +0800 From: "carriez" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2006 13:11:48.0422 (UTC) FILETIME=[C79F2660:01C67FFC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [rohc] Announce SIP/SDP Static Dictionarty in Returned Parameter? 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: , Errors-To: rohc-bounces@ietf.org Hi experts, I have a question regarding whether the SIP/SDP static dictionary should be announced in the returned parameter when the I-bit is set to 0 in the incoming SigComp message? RFC3320 section 9.4.9 defines that when the I-bit is set to 0 in the requested feedback, it means the sending side still wishes to access the locally available state items offered by the receiving endpoint, and the receiving side should announce its local available in the returned parameter defined in the same section. While we intepretate that the SIP/SDP static dictionary defined in RFC3485 is a MUST HAVE for all SIP endpoints that support SigComp. If it is required to be there, is the overhead to advertise it necessary? Thanks in advance. Regards, Carrie _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 26 08:58:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjbti-0006DY-Dg; Fri, 26 May 2006 08:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjbth-0006Co-BG for rohc@ietf.org; Fri, 26 May 2006 08:58:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjbth-0006kX-9n for rohc@ietf.org; Fri, 26 May 2006 08:58:33 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjbjW-0007Ka-C4 for rohc@ietf.org; Fri, 26 May 2006 08:48:08 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 486764F0001 for ; Fri, 26 May 2006 14:48:00 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 14:48:00 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 14:47:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Context(Tsc) Date: Fri, 26 May 2006 14:47:58 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502EC0AE5@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Context(Tsc) Thread-Index: AcaAlDUbtGw99bmWRhmbwIX7JVX4jwAJXV9Q From: "Ghyslain Pelletier \(LU/EAB\)" To: X-OriginalArrivalTime: 26 May 2006 12:47:59.0977 (UTC) FILETIME=[9E9D7D90:01C680C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: rohc-bounces@ietf.org Hi Endre, =20 > it is completely meaningless to suggest, that Tsc is one of the > values that should be kept in the context This is for consistency with 3095. 3095 is a specification that describes a protocol with respect to interoperability, not how to implement the protocol, although sometimes it unfortunately clearly leads implementers. Context(Tsc) is only used to convey the meaning "unless the Tsc flag in EXT_3 says otherwise, the TS bits in the extension are always scaled TS bits". Note also that sections 6.5.1 and 6.5.2 in 3095 are informative: "It is not intended to constrain the implementations." However, you may want to reconsider your statement after reading "5.7.5.2. Flags/Fields in context": Flag/Field Initial value Comment --------------------------------------------------------------------- Tsc 1 Tsc is always 1 in context; can be 0 only when an Extension 3 is present. See the discussion of the TS field in the beginning of section 5.7. ;-) /Ghyslain =20 > Hi ROHCers, >=20 > A minor suggestion: > Section 4.7 in the "Corrections and Clarifications to RFC 3095" > (draft-ietf-rohc-rtp-impl-guide-19.txt) document mentions that: > "Context(Tsc) is always 1. If scaling is not desired, the compressor > will establish TS_STRIDE =3D 1." >=20 > Beside that Tsc is not listed in section 6.5.1 and 6.5.2 of RFC 3095; > it is completely meaningless to suggest, that Tsc is one of the > values that should be kept in the context, since its value is always > constant, never updated. Tsc has effect only on the current packet, > never on packets after that. I think it would be better to remove > the first sentence "Context(Tsc) is always 1."=20 >=20 > Regards, > Endre _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 26 09:03:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjby6-0000hj-LU; Fri, 26 May 2006 09:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjby5-0000he-6f for rohc@ietf.org; Fri, 26 May 2006 09:03:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjbxy-0007dH-D3 for rohc@ietf.org; Fri, 26 May 2006 09:03:05 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A6C2C4F0001 for ; Fri, 26 May 2006 15:02:51 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 15:02:51 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 15:02:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] "(no subject)" Date: Fri, 26 May 2006 15:02:50 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502EC0AE6@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] "(no subject)" Thread-Index: AcaAlLw4sHBLThiWRMOqh4u/OPnpdAAJLbVQ From: "Ghyslain Pelletier \(LU/EAB\)" To: X-OriginalArrivalTime: 26 May 2006 13:02:51.0365 (UTC) FILETIME=[B1EC8150:01C680C4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: rohc-bounces@ietf.org Hi Endre, We've removed the mention for the 'generic extension header list', because rfc3095 is clear about its length and how it works, as you point out yourself in your mail. We wanted to clarify only for the 'generic CSRC list', because the presence of the CC field in the dynamic RTP chain described in 5.7.7.6 combined with the possible association that the reader might make with the way CSRC list works in RTP could still represent a possible source of misinterpretation of the specification. /Ghyslain > Hi ROHCers, >=20 > Section 5.1 of the "Corrections and Clarifications to RFC 3095" > (draft-ietf-rohc-rtp-impl-guide-19.txt) document clarifies that the > 'Generic CSRC list' field is always at least 1 octet, even if the > list is empty.=20 >=20 > This statement was already present in the previous version of the > document, but for IP extension header only. Now it covers CSRC list > only.=20 >=20 > Since the statement is true both for IP extension header lists and > for CSRC lists, I suggest to correct the paragraph and its title to > cover both cases:=20 >=20 > 5.1. Generic extension header list and generic CSRC list >=20 > The 'generic extension header list' and the 'generic CSRC list' > fields start with an octet that is always present, so its length > is one octet, at least.=20 >=20 > Regards, > Endre _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 26 14:01:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgcx-0007rN-Qo; Fri, 26 May 2006 14:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgcw-0007rI-Ux for rohc@ietf.org; Fri, 26 May 2006 14:01:34 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjgcn-0001GK-Bd for rohc@ietf.org; Fri, 26 May 2006 14:01:34 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6667F4F002E for ; Fri, 26 May 2006 20:01:16 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 20:01:15 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 20:01:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] "SC-FC ping pong" Date: Fri, 26 May 2006 20:01:14 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502EC0AF1@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] "SC-FC ping pong" Thread-Index: AcaAl4kMnSGUV2cyQvyUwRlWZzthMAAIlYPQ From: "Ghyslain Pelletier \(LU/EAB\)" To: X-OriginalArrivalTime: 26 May 2006 18:01:15.0351 (UTC) FILETIME=[6187F670:01C680EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Errors-To: rohc-bounces@ietf.org Hi Lajos, The situation that you are describing seems to be an example of a very bad compressor and a very bad decompressor implementation. You are addressing parts of the 3095 specifications that are left open to implementers, i.e. decompressor feedback logic, recovery and compressor robustness. I understand that you would like to ensure that a good implementation does not suffer from interacting with another, less good implementation. Specifications cannot cover for bad design choices. So, I do not think that this needs be solved through more standard text. A smart implementer will make sure that its decompressor monitors what it has tried to update in conjunction with the SN received in the feedback to produce proper repairs when receiving NACKs (and/or Static-NACKs). Similarly, a smart implementer will make sure that upon repeated failures of packet types other than IR and/or IR-DYN, i.e. repeated failures of packets that verify the outcome of the decompression process (thus including the static part), a Static-NACK would ultimately be sent. Note finally that it would be a rather bad design choice for a compressor not to make use of the SN it receives in a feedback, e.g. in a NACK(SN=3DX), to figure out that it has sent IR packets since that particular SN=3DX. /Ghyslain > Hi RoHCers, >=20 > Say the decompressor is in state FC, and the compressor wants to > update a field in static part (O-mode). Say the OA period is short > and all updating IR packets are lost. The subsequent UO-0 packets > cannot be successfully decompressed due to the old static field. As > a result, the decompressor transits to state SC and probably sends > NACK, after some CRC failures (there is no way for the decompressor > to find out what went wrong). In this case, it is completely legal > for the compressor to send IR-DYN - even though the earlier update > of a field in the static part may be a good reason not to do so. On > receipt of the IR-DYN, the decompressor happily transits from SC to > FC (even though the IR-DYN is also incorrect as the > CRC-8 does not protect the original header), but alas, the UO-0 > packets would fail again, driving the couple to a neverending story. > The decompressor would produce only packets with incorrect header > when IR-DYN received and nothing (besides CRC failure) otherwise. >=20 > I think, the problem is that the specification does not prohibit such > a situation. We may call it deadlock, because there is no way to > recover. This (maybe simple but still RFC 3095 compliant) compressor > would never learn about the failure. >=20 > I can recommend two alternatives that guarantee recovery: > a) Explicitly require compressors to avoid sending IR-DYN in such > cases; or b) do not let decompressors to transit from SC to FC after > successful decompression of IR-DYN, which would drive it to state SC > after some CRC failures and so to send STATIC-NACK. >=20 > Looking forward to reading your opinion and comments. >=20 > Best regards, > Zacco _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 26 14:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjhJy-0004e1-AI; Fri, 26 May 2006 14:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjhJw-0004dg-Mh for rohc@ietf.org; Fri, 26 May 2006 14:46:00 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjhJv-0004HP-DK for rohc@ietf.org; Fri, 26 May 2006 14:46:00 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4QIjwPr013860 for ; Fri, 26 May 2006 14:45:58 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4QIjwl6271154 for ; Fri, 26 May 2006 12:45:58 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4QIjwtg023802 for ; Fri, 26 May 2006 12:45:58 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4QIjwtn023772; Fri, 26 May 2006 12:45:58 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k4QIjvcN023278; Fri, 26 May 2006 14:45:57 -0400 Message-Id: <200605261845.k4QIjvcN023278@rotala.raleigh.ibm.com> To: rohc@ietf.org Date: Fri, 26 May 2006 14:45:57 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: AC Mahendran Subject: [rohc] Liaison request from 3GPP2 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: , Errors-To: rohc-bounces@ietf.org ROHC WG: 3GPP2 has sent the following request to the ROHC WG. > The RoHC WG is currently working on revising the IP/UDP/RTP profiles > defined in RFC 3095 to add support for reordering among other > things. Reordering support in RoHC is extremely important for 3GPP2, > since packets can arrive out-of-order due to handoffs as well as ARQ > techniques at the physical and higher layers. Based on the RoHC WG > charter, the WG is expected to produce a couple of related documents ­ > RoHC framework draft and Revised IP/UDP/RTP profiles draft. > Both these documents are essential for 3GPP2. We would greatly > appreciate it if you could provide us the target completion dates of > the above drafts. Also, we request that the work on these documents > be completed as soon as possible. (It doesn't appear the WG has discussed these, as I find no record in the WG archives. Also, I can't tell of ROHC met in Dallas. There was a slot for ROHC on the published agenda, but the proceedings say the WG didn't meet.) Can someone please report on the status of the following two documents: - draft-ietf-rohc-rfc3095bis-framework - draft-ietf-rohc-rfc3095bis-improvements Are they close to being finished? Are there known outstanding issues that need to be addressed? Thomas _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri May 26 15:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fji0u-0000fv-7X; Fri, 26 May 2006 15:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fji0s-0000fp-UW for rohc@ietf.org; Fri, 26 May 2006 15:30:22 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fji0j-0001SN-7U for rohc@ietf.org; Fri, 26 May 2006 15:30:22 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 057CB4F0003; Fri, 26 May 2006 21:29:38 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 21:29:37 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 21:29:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Liaison request from 3GPP2 Date: Fri, 26 May 2006 21:29:32 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502EC0AF5@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Liaison request from 3GPP2 Thread-Index: AcaA9M5fRsFf6trwSmmGcR5zhnb5KQAA+AoA From: "Ghyslain Pelletier \(LU/EAB\)" To: "Thomas Narten" , X-OriginalArrivalTime: 26 May 2006 19:29:37.0171 (UTC) FILETIME=[B9A97E30:01C680FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: AC Mahendran 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: , Errors-To: rohc-bounces@ietf.org Thomas, RoHCers, The output that 3GPP2 expect from this WG in the liaison is actually = three documents: - draft-ietf-rohc-rfc3095bis-improvements (to be published as = Informational) - draft-ietf-rohc-rfc3095bis-framework (to be published as PS) - RoHCv2 profiles (to be published as PS, does not exist publicly yet) So, there is a whole draft missing here as you can see. I've already = notified Rohit Kapoor (which I believe is involved in 3GPP2 std?) that I = will submit a draft describing the updated RoHC profiles (RoHCv2 = profiles) by the cut-off date for initial submissions. I have already = notified the WG chair of the upcoming draft as well. Look for = draft-pelletier-rohcv2-profiles-00.txt by mid-June. I've already = updating my priority list with this one on top. Status: =20 > - draft-ietf-rohc-rfc3095bis-framework This draft specifies the RoHC framework. It does not include any update = to profiles. In my opinion, it is already ready for a wglc, however = there is no point in having a wglc until its companion draft describing = the updated profiles (RoHCv2 profiles) is also ready for wlgc. Currently = as I wrote above, this draft only exists on my computer, i.e. it is yet = to be available as a draft individual submission, but I'm a couple of = week for making it available. > - draft-ietf-rohc-rfc3095bis-improvements This draft is meant to be published as informational. It contains = suggested improvement for the updated RoHC profiles (RoHCv2 profiles) as = agreed on the mailing list. However, it is of not really of any help to = 3GPP2 as it only describes what should be done for the RoHCv2 profiles. = It is some kind of "requirements" document =20 > Are they close to being finished? Are there known outstanding > issues that need to be addressed? I think there has been only limited discussions of the framework and the = improvements draft on the mailing list, nothing at a physical meeting. = The RoHC WG hasn't met at last IETF. I am not sure yet if there will be = a WG meeting in Montreal, but I think it may be good to have one to = discuss how to move forward on this issue. Should we push the chairman = to request a meeting slot in Montreal? Any opinions? Anyone interested = in meeting physically to discuss how to move this work forward once I've = sent in the base draft for the updated profiles? Regards, /Ghyslain -- Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 8 404 29 43 Mobile: +46 (0) 70 264 83 14 Ghyslain.Pelletier at ericsson.com http://www.ericsson.com ----------------------------------- The opinions expressed in this message are my personal opinions. These opinions are not necessarily those of my employer, unless stated otherwise. ----------------------------------- Thomas Narten wrote: > ROHC WG: >=20 > 3GPP2 has sent the following request to the ROHC WG. >=20 >> The RoHC WG is currently working on revising the IP/UDP/RTP profiles >> defined in RFC 3095 to add support for reordering among other things. >> Reordering support in RoHC is extremely important for 3GPP2, since >> packets can arrive out-of-order due to handoffs as well as ARQ >> techniques at the physical and higher layers. Based on the RoHC WG >> charter, the WG is expected to produce a couple of related documents >> =C2=AD RoHC framework draft and Revised IP/UDP/RTP profiles draft. >=20 >> Both these documents are essential for 3GPP2. We would greatly >> appreciate it if you could provide us the target completion dates of >> the above drafts. Also, we request that the work on these documents >> be completed as soon as possible. >=20 > (It doesn't appear the WG has discussed these, as I find no > record in the WG archives. Also, I can't tell of ROHC met in > Dallas. There was a slot for ROHC on the published agenda, > but the proceedings say the WG didn't meet.) >=20 > Can someone please report on the status of the following two > documents:=20 >=20 > - draft-ietf-rohc-rfc3095bis-framework > - draft-ietf-rohc-rfc3095bis-improvements >=20 > Are they close to being finished? Are there known outstanding > issues that need to be addressed? >=20 > Thomas >=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 Mon May 29 05:07:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkdiA-0008UM-WD; Mon, 29 May 2006 05:06:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkdi9-0008Oa-Nz for rohc@ietf.org; Mon, 29 May 2006 05:06:53 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkdi3-00063E-R8 for rohc@ietf.org; Mon, 29 May 2006 05:06:53 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4T96jST003300 for ; Mon, 29 May 2006 04:06:46 -0500 (CDT) Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 May 2006 17:05:51 +0800 Received: from [135.252.136.92] ([135.252.136.92]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 May 2006 17:05:51 +0800 Message-ID: <447AB96F.3030807@lucent.com> Date: Mon, 29 May 2006 17:05:51 +0800 From: "carriez" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Subject: Re: [rohc] Announce SIP/SDP Static Dictionarty in Returned Parameter? References: <4475AD11.8020001@lucent.com> In-Reply-To: <4475AD11.8020001@lucent.com> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2006 09:05:51.0509 (UTC) FILETIME=[1577EC50:01C682FF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: rohc-bounces@ietf.org Hi experts, Can anyone please help to answer my question below? Thanks a lot. Regards, Carrie carriez wrote: > Hi experts, > > I have a question regarding whether the SIP/SDP static dictionary > should be announced in the returned parameter when the I-bit is set > to 0 in the incoming SigComp message? > > RFC3320 section 9.4.9 defines that when the I-bit is set to 0 in the > requested feedback, it means the sending side still wishes to access > the locally available state items offered by the receiving endpoint, > and the receiving side should announce its local available in the > returned parameter defined in the same section. > > While we intepretate that the SIP/SDP static dictionary defined in > RFC3485 is a MUST HAVE for all SIP endpoints that support SigComp. If > it is required to be there, is the overhead to advertise it necessary? > > Thanks in advance. > > Regards, > Carrie > > > _______________________________________________ > 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 May 29 07:51:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkgHn-0003Bl-UK; Mon, 29 May 2006 07:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkgHm-0003Bg-Rv for rohc@ietf.org; Mon, 29 May 2006 07:51:50 -0400 Received: from [203.101.112.21] (helo=mail2.sonimtech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkgHl-00052Y-9L for rohc@ietf.org; Mon, 29 May 2006 07:51:50 -0400 content-class: urn:content-classes:message Subject: RE: [rohc] Announce SIP/SDP Static Dictionarty in Returned Parameter? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 May 2006 17:21:41 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Announce SIP/SDP Static Dictionarty in Returned Parameter? Thread-Index: AcaC/5IMl2oXkE0JSjOUvGiT1kX/tgAFgB6g From: "Vishal Sudan" To: "carriez" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: , Errors-To: rohc-bounces@ietf.org Hi, The 3485 SIP/SDP dictionary state is termed a "mandatory state" and not = a "locally available state", so its presence need not be advertized. You can refer to = http://www1.ietf.org/mail-archive/web/rohc/current/msg04187.html and = relevant discussions. Thanks and Regards, Vishal Sudan -----Original Message----- From: carriez [mailto:carriez@lucent.com] Sent: Monday, May 29, 2006 2:36 PM To: rohc@ietf.org Subject: Re: [rohc] Announce SIP/SDP Static Dictionarty in Returned Parameter? Hi experts, Can anyone please help to answer my question below? Thanks a lot. Regards, Carrie carriez wrote: > Hi experts, >=20 > I have a question regarding whether the SIP/SDP static dictionary > should be announced in the returned parameter when the I-bit is set > to 0 in the incoming SigComp message? >=20 > RFC3320 section 9.4.9 defines that when the I-bit is set to 0 in the > requested feedback, it means the sending side still wishes to access > the locally available state items offered by the receiving endpoint, > and the receiving side should announce its local available in the > returned parameter defined in the same section. >=20 > While we intepretate that the SIP/SDP static dictionary defined in > RFC3485 is a MUST HAVE for all SIP endpoints that support SigComp. If > it is required to be there, is the overhead to advertise it necessary? >=20 > Thanks in advance. >=20 > Regards, > Carrie >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 29 13:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fklgt-0001Tp-O6; Mon, 29 May 2006 13:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fklgr-0001Lu-KU for rohc@ietf.org; Mon, 29 May 2006 13:38:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkjw9-00017Y-I6 for rohc@ietf.org; Mon, 29 May 2006 11:45:45 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fkjmf-0006tc-CD for rohc@ietf.org; Mon, 29 May 2006 11:35:58 -0400 Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id 0E87320A6D5 for ; Mon, 29 May 2006 15:35:22 +0000 (UTC) Received: by shell.iptel.org (sSMTP sendmail emulation); Mon, 29 May 2006 17:36:15 +0200 Date: Mon, 29 May 2006 17:36:15 +0200 From: Cristian Constantin To: rohc@ietf.org Message-ID: <20060529153615.GB21263@shell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [rohc] useful values torture test 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: , Errors-To: rohc-bounces@ietf.org hi! pls. refer to http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-torture-tests-03.txt section "3.1 Useful Values". in my oppionion the outcome of the test when run with sms=2K (as spec in the section "1. Introduction") is different from the one described in the draft. the test makes use of the stored bytecode; here is a more or less detailed description of what happens: 1. bytecode on the wire; END-MESSAGE just stores the "initial bytecode". (as a side note, besides some exec code it contains some data as well 0x0040 - 0x0080; why?) state memory = {S1(1024)} 2. bytecode accessed from state S1; END-MESSAGE stores again some bytecode. however the "data" portion of it is different from the first one. state memory = {S2(1024), S1(1024)} 3. bytecode accessed from state S1; END-MESSAGE stores again some bytecode. however the "data" portion of it is different from the first and the second one; S1 gets deleted. state memory = {S3(1024), S2(1024)} 4. bytecode accessed from state S1; S1 is no longer there. error, but different from what is spec in the draft. if I'm right, then a possible solution would be that END-MESSAGE does not always save bytecode but only at the first packet; if not pls. let me know where is my mistake. bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 30 02:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fky3r-0005H8-K7; Tue, 30 May 2006 02:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fky3p-0005H3-Lp for rohc@ietf.org; Tue, 30 May 2006 02:50:37 -0400 Received: from [203.101.112.21] (helo=mail2.sonimtech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fky3o-0000O8-3h for rohc@ietf.org; Tue, 30 May 2006 02:50:37 -0400 content-class: urn:content-classes:message Subject: RE: [rohc] useful values torture test MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 May 2006 12:20:33 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] useful values torture test Thread-Index: AcaDRxgqQfnHW8/oTJa9baqs58oG7gAbO5iw From: "Vishal Sudan" To: "Cristian Constantin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: rohc-bounces@ietf.org Hi Cristian, That the third test is supposed to give decompression failure explains = it. In=20 such a case the third state does'nt get saved and S1 does'nt get deleted = - decompression=20 terminates before reaching END-MESSAGE. Of course, as the doc says=20 "A liberal implementation could allow more cycles to be used than are = strictly available, in which case decompression failure will not occur" So if your 3rd test passes it would seem you are of liberal attitude. Thanks, Vishal Sudan =20 -----Original Message----- From: Cristian Constantin [mailto:cristian.constantin@iptel.org] Sent: Monday, May 29, 2006 9:06 PM To: rohc@ietf.org Subject: [rohc] useful values torture test hi! pls. refer to http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-torture-tests= -03.txt section "3.1 Useful Values". in my oppionion the outcome of the test when run with sms=3D2K (as spec = in the section "1. Introduction") is different from the one described=20 in the draft. the test makes use of the stored bytecode; here is a more or less detailed description of what happens: 1. bytecode on the wire; END-MESSAGE just stores the "initial bytecode". (as a side note, besides some exec code it contains some data as=20 well 0x0040 - 0x0080; why?) state memory =3D {S1(1024)} 2. bytecode accessed from state S1; END-MESSAGE stores again some bytecode. however the "data" portion of it is different from the first one.=20 state memory =3D {S2(1024), S1(1024)} 3. bytecode accessed from state S1; END-MESSAGE stores again some bytecode. however the "data" portion of it is different from the first and the second one; S1 gets deleted. state memory =3D {S3(1024), S2(1024)} 4. bytecode accessed from state S1; S1 is no longer there. error, but different from what is spec in the draft. if I'm right, then a possible solution would be that END-MESSAGE does not always save bytecode but only at the first packet; if not pls. let me know where is my mistake. bye now! cristian _______________________________________________ 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 May 30 04:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkzgd-0000eN-Ky; Tue, 30 May 2006 04:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkzgc-0000eI-Nx for rohc@ietf.org; Tue, 30 May 2006 04:34:46 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkzgb-0000SO-Ek for rohc@ietf.org; Tue, 30 May 2006 04:34:46 -0400 Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id 7A48420A0C0; Tue, 30 May 2006 08:34:11 +0000 (UTC) Received: by shell.iptel.org (sSMTP sendmail emulation); Tue, 30 May 2006 08:35:06 +0000 Date: Tue, 30 May 2006 08:35:06 +0000 From: Cristian Constantin To: Vishal Sudan Subject: Re: [rohc] useful values torture test Message-ID: <20060530083506.GA23488@shell> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: rohc-bounces@ietf.org On Tue, May 30, 2006 at 12:20:33PM +0530, Vishal Sudan wrote: > Hi Cristian, > > That the third test is supposed to give decompression failure explains it. In > such a case the third state does'nt get saved and S1 does'nt get deleted - decompression > terminates before reaching END-MESSAGE. > > Of course, as the doc says > "A liberal implementation could allow more cycles to be used than are strictly > available, in which case decompression failure will not occur" > > So if your 3rd test passes it would seem you are of liberal attitude. cristian: yes, you're right. I'm allowing more cycles and I guess that's why the extra state gets created. however I still don't get it why the bytecode has to be always saved; only the one saved the first time gets to be used. thanks! bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 30 06:05:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl168-00063Z-Pm; Tue, 30 May 2006 06:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl167-00063U-HV for rohc@ietf.org; Tue, 30 May 2006 06:05:11 -0400 Received: from [203.101.112.21] (helo=mail2.sonimtech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl165-0000Pg-PK for rohc@ietf.org; Tue, 30 May 2006 06:05:11 -0400 content-class: urn:content-classes:message Subject: RE: [rohc] useful values torture test MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 May 2006 15:35:06 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] useful values torture test Thread-Index: AcaDw+orWh0Ji1RNQUeo9NkboOKdcAACoEYw From: "Vishal Sudan" To: "Cristian Constantin" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Errors-To: rohc-bounces@ietf.org > however I still don't get it why the bytecode has to be always saved; > only the one saved the first time gets to be used. Thats true. And the document does the same with (almost?) all the = bytecodes saved=20 in the torture tests. One major disadvantage is that it makes the sample = bytecodes "non-standard" so that the implementers cannot optimize decompression by = not running=20 the UDVM for possbly "standard" bytecodes. I guess standard bytecodes = were eschewed=20 cause variables like "circular_buffer" used for LZ77 are determined by = the DMS.=20 I personally would prefer to have standard bytecodes so that their = decompression=20 could be optimized. Maybe this requirement calls for a efficient = compression algorithm=20 to be made available in open source. Thanks, Vishal Sudan -----Original Message----- From: Cristian Constantin [mailto:cristian.constantin@iptel.org] Sent: Tuesday, May 30, 2006 2:05 PM To: Vishal Sudan Cc: rohc@ietf.org Subject: Re: [rohc] useful values torture test On Tue, May 30, 2006 at 12:20:33PM +0530, Vishal Sudan wrote: > Hi Cristian, >=20 > That the third test is supposed to give decompression failure explains = it. In=20 > such a case the third state does'nt get saved and S1 does'nt get = deleted - decompression=20 > terminates before reaching END-MESSAGE. >=20 > Of course, as the doc says=20 > "A liberal implementation could allow more cycles to be used than = are strictly > available, in which case decompression failure will not occur" >=20 > So if your 3rd test passes it would seem you are of liberal attitude. cristian: yes, you're right. I'm allowing more cycles and I guess that's why the extra state gets created. however I still don't get it why the bytecode has to be always saved; only the one saved the first time gets to be used. thanks! bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 30 19:14:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDQ2-00019u-3P; Tue, 30 May 2006 19:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPy-00014S-15; Tue, 30 May 2006 19:14:30 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlDPw-0001NS-Lz; Tue, 30 May 2006 19:14:30 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4UNESKQ018970; Tue, 30 May 2006 16:14:28 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4UNESVn018969; Tue, 30 May 2006 16:14:28 -0700 Date: Tue, 30 May 2006 16:14:28 -0700 Message-Id: <200605302314.k4UNESVn018969@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: rohc@ietf.org, rfc-editor@rfc-editor.org Subject: [rohc] RFC 4464 on Signaling Compression (SigComp) Users' 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: , Errors-To: rohc-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4464 Title: Signaling Compression (SigComp) Users' Guide Author: A. Surtees, M. West Status: Informational Date: May 2006 Mailbox: abigail.surtees@roke.co.uk, mark.a.west@roke.co.uk Pages: 43 Characters: 79643 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rohc-sigcomp-user-guide-04.txt URL: http://www.rfc-editor.org/rfc/rfc4464.txt This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. This memo provides information for the Internet community. This document is a product of the Robust Header Compression Working Group of the IETF. INFORMATIONAL: 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 ... _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 31 08:18:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPeD-0004Ky-Fn; Wed, 31 May 2006 08:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkfZE-0007PL-MN for rohc@ietf.org; Mon, 29 May 2006 07:05:49 -0400 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkfZC-0000jM-RC for rohc@ietf.org; Mon, 29 May 2006 07:05:48 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.13.6) with ESMTP id l4RB582O015848 for ; Sun, 27 May 2007 16:35:09 +0530 To: Gonzalo.Camarillo@ericsson.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Ankita Taparia Date: Mon, 29 May 2006 16:34:31 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/29/2006 04:34:34 PM, Serialize complete at 05/29/2006 04:34:34 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Wed, 31 May 2006 08:18:00 -0400 Cc: Subject: [rohc] Retransmission of uncompressed message in case of client transaction time out 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="===============1339151641==" Errors-To: rohc-bounces@ietf.org This is a multipart message in MIME format. --===============1339151641== Content-Type: multipart/alternative; boundary="=_alternative 003CE90A6525717D_=" This is a multipart message in MIME format. --=_alternative 003CE90A6525717D_= Content-Type: text/plain; charset="US-ASCII" Hi , In the Error Situations the rfc 3486 states that - " If a SIP client sends a compressed request and the client transaction times out without having received any response, the client SHOULD retry the same request without using compression. " However in such a scenario ,if the client transaction waits for the the time out duration , and then retransmits the uncompressed message then the previous hop will by that time itself will get timed out as a provisional response is received only in case of the INVITE request . Hence the retransmission will not serve the purpose . How would such a situation be taken care of? Regards Ankita Taparia Intern , FSS *********************** FSS-Restricted *********************** *********************** FSS-Unclassified *********************** --=_alternative 003CE90A6525717D_= Content-Type: text/html; charset="US-ASCII"

Hi ,

In the Error Situations the rfc 3486 states that  -

"  If a SIP client sends a compressed request and the client transaction
   times out without having received any response, the client SHOULD
   retry the same request without using compression. "

However in such a scenario ,if the client transaction waits for the the time out duration , and then retransmits the uncompressed message
then the previous hop will by that time itself will get timed out as a provisional response is received only in case of the INVITE request .
 Hence the retransmission will not serve the purpose . How would such a situation  be taken care of?  


Regards
Ankita Taparia
Intern , FSS
 


***********************  FSS-Restricted   ***********************

***********************  FSS-Unclassified   *********************** --=_alternative 003CE90A6525717D_=-- --===============1339151641== 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 --===============1339151641==-- From rohc-bounces@ietf.org Wed May 31 10:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlReN-0006XD-Vi; Wed, 31 May 2006 10:26:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlReM-0006X8-Hy for rohc@ietf.org; Wed, 31 May 2006 10:26:18 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlReC-0008Hx-Uk for rohc@ietf.org; Wed, 31 May 2006 10:26:18 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2CFB64F0007; Wed, 31 May 2006 16:26:06 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:26:03 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:26:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Liaison request from 3GPP2 Date: Wed, 31 May 2006 16:27:31 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502F59B49@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Liaison request from 3GPP2 Thread-Index: AcaA9M5fRsFf6trwSmmGcR5zhnb5KQAA+AoAAPDxpPA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Thomas Narten" , X-OriginalArrivalTime: 31 May 2006 14:26:03.0528 (UTC) FILETIME=[258CE080:01C684BE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: AC Mahendran 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: , Errors-To: rohc-bounces@ietf.org Thomas, Ghyslain, others, (filling in some details in the excellent summary from Ghyslain) > Thomas, RoHCers, >=20 > The output that 3GPP2 expect from this WG in the liaison is actually > three documents:=20 >=20 > - draft-ietf-rohc-rfc3095bis-improvements (to be published > as Informational) > - draft-ietf-rohc-rfc3095bis-framework (to be published as PS) > - RoHCv2 profiles (to be published as PS, does not exist publicly yet)=20 >=20 > So, there is a whole draft missing here as you can see. I've > already notified Rohit Kapoor (which I believe is involved in > 3GPP2 std?) that I will submit a draft describing the updated > RoHC profiles (RoHCv2 profiles) by the cut-off date for > initial submissions. I have already notified the WG chair of > the upcoming draft as well. Look for > draft-pelletier-rohcv2-profiles-00.txt by mid-June. That is excellent, I hope we can then get discussions going on this draft, and the intent would then be to turn this document into the envisioned WG draft. Ghyslain, for alignment with the WG draft name, which will be: draft-ietf-rohc-rfc3095bis-profiles-00.txt, please name the upcoming initial individual draft similarily: draft-pelletier-rohc-rfc3095bis-profiles-00.txt > Status: >=20 >> - draft-ietf-rohc-rfc3095bis-framework >=20 > This draft specifies the RoHC framework. It does not include > any update to profiles. In my opinion, it is already ready > for a wglc, however there is no point in having a wglc until > its companion draft describing the updated profiles (RoHCv2 > profiles) is also ready for wlgc. Currently as I wrote above, > this draft only exists on my computer, i.e. it is yet to be > available as a draft individual submission, but I'm a couple > of week for making it available. >=20 >> - draft-ietf-rohc-rfc3095bis-improvements >=20 > This draft is meant to be published as informational. It > contains suggested improvement for the updated RoHC profiles > (RoHCv2 profiles) as agreed on the mailing list. However, it > is of not really of any help to 3GPP2 as it only describes > what should be done for the RoHCv2 profiles. It is some kind > of "requirements" document >=20 >> Are they close to being finished? Are there known outstanding >> issues that need to be addressed? >=20 > I think there has been only limited discussions of the > framework and the improvements draft on the mailing list, > nothing at a physical meeting. Well, the improvements draft has been discussed point-by-point before it even became a separate draft (discussions were=20 carried out while it was part of draft-ietf-rohc-rtp-impl-guide), establishing consensus for all items. However, I believe it is reasonable to believe some people may have additional ideas to bring for v2, and such ideas should then be brought to the mail list. If not, the improvements draft as it currently looks is what consitutes the technical direction for the profiles draft. > Should we push the chairman to request a meeting slot in > Montreal? Any opinions? A meeting slot will be requested! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 31 10:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRk2-0000oB-7y; Wed, 31 May 2006 10:32:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRk0-0000o1-7n for rohc@ietf.org; Wed, 31 May 2006 10:32:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRjy-0000P6-Nj for rohc@ietf.org; Wed, 31 May 2006 10:32:08 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 94EA64F007F; Wed, 31 May 2006 16:31:55 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:31:55 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:31:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Liaison request from 3GPP2 Date: Wed, 31 May 2006 16:31:54 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502F59B57@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Liaison request from 3GPP2 Thread-Index: AcaA9M5fRsFf6trwSmmGcR5zhnb5KQAA+AoAAPDxpPAAAHJkMA== From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Thomas Narten" , X-OriginalArrivalTime: 31 May 2006 14:31:55.0024 (UTC) FILETIME=[F70EE900:01C684BE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: AC Mahendran 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: , Errors-To: rohc-bounces@ietf.org Lars-Erik, > Ghyslain, for alignment with the WG draft name, which will be: > draft-ietf-rohc-rfc3095bis-profiles-00.txt, > please name the upcoming initial individual draft similarily: > draft-pelletier-rohc-rfc3095bis-profiles-00.txt I don't really agree with this, as the RoHCv2 profiles are not meant to replace the already existing profiles, but rather to create an updated variants without replacing the current profiles. In other words, new profile numbers should be issued by IANA. So I don't see the RoHCv2 profiles draft having the "bis" in its name. For the framework draft, it is already borderline but less of an issue as it is compatible with RFC3095, but I am not sure it is really a "bis" either, unless a bis can update and replace only a part of an existing specification. /Ghyslain Lars-Erik Jonsson (LU/EAB) wrote: > Thomas, Ghyslain, others, >=20 > (filling in some details in the excellent summary from Ghyslain) >=20 >> Thomas, RoHCers, >>=20 >> The output that 3GPP2 expect from this WG in the liaison is actually >> three documents:=20 >>=20 >> - draft-ietf-rohc-rfc3095bis-improvements (to be published as >> Informational)=20 >> - draft-ietf-rohc-rfc3095bis-framework (to be published as PS) >> - RoHCv2 profiles (to be published as PS, does not exist > publicly yet) >>=20 >> So, there is a whole draft missing here as you can see. I've already >> notified Rohit Kapoor (which I believe is involved in >> 3GPP2 std?) that I will submit a draft describing the updated RoHC >> profiles (RoHCv2 profiles) by the cut-off date for initial >> submissions. I have already notified the WG chair of the upcoming >> draft as well. Look for draft-pelletier-rohcv2-profiles-00.txt by >> mid-June. >=20 > That is excellent, I hope we can then get discussions going > on this draft, and the intent would then be to turn this > document into the envisioned WG draft. >=20 > Ghyslain, for alignment with the WG draft name, which will be: > draft-ietf-rohc-rfc3095bis-profiles-00.txt, > please name the upcoming initial individual draft similarily: > draft-pelletier-rohc-rfc3095bis-profiles-00.txt >=20 >=20 >> Status: >>=20 >>> - draft-ietf-rohc-rfc3095bis-framework >>=20 >> This draft specifies the RoHC framework. It does not include any >> update to profiles. In my opinion, it is already ready for a wglc, >> however there is no point in having a wglc until its companion draft >> describing the updated profiles (RoHCv2 >> profiles) is also ready for wlgc. Currently as I wrote above, this >> draft only exists on my computer, i.e. it is yet to be available as a >> draft individual submission, but I'm a couple of week for making it >> available.=20 >>=20 >>> - draft-ietf-rohc-rfc3095bis-improvements >>=20 >> This draft is meant to be published as informational. It contains >> suggested improvement for the updated RoHC profiles >> (RoHCv2 profiles) as agreed on the mailing list. However, it is of >> not really of any help to 3GPP2 as it only describes what should be >> done for the RoHCv2 profiles. It is some kind of "requirements" >> document=20 >>=20 >>> Are they close to being finished? Are there known outstanding issues >>> that need to be addressed? >>=20 >> I think there has been only limited discussions of the framework and >> the improvements draft on the mailing list, nothing at a physical >> meeting. >=20 > Well, the improvements draft has been discussed > point-by-point before it even became a separate draft > (discussions were carried out while it was part of > draft-ietf-rohc-rtp-impl-guide), establishing consensus for > all items. However, I believe it is reasonable to believe > some people may have additional ideas to bring for v2, and > such ideas should then be brought to the mail list. If not, > the improvements draft as it currently looks is what > consitutes the technical direction for the profiles draft. >=20 >> Should we push the chairman to request a meeting slot in Montreal? >> Any opinions? >=20 > A meeting slot will be requested! >=20 > /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 31 10:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRuR-0005mV-84; Wed, 31 May 2006 10:42:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRuP-0005mQ-UD for rohc@ietf.org; Wed, 31 May 2006 10:42:53 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRuI-0001LF-FK for rohc@ietf.org; Wed, 31 May 2006 10:42:53 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EC2594F0002; Wed, 31 May 2006 16:42:45 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:42:45 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:42:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Liaison request from 3GPP2 Date: Wed, 31 May 2006 16:44:13 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0502F59B6B@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Liaison request from 3GPP2 Thread-Index: AcaA9M5fRsFf6trwSmmGcR5zhnb5KQAA+AoAAPDxpPAAAHJkMAAASfrw From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Thomas Narten" , X-OriginalArrivalTime: 31 May 2006 14:42:44.0917 (UTC) FILETIME=[7A6CB650:01C684C0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: AC Mahendran 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: , Errors-To: rohc-bounces@ietf.org Ghyslain,=20 > Lars-Erik, >=20 >> Ghyslain, for alignment with the WG draft name, which will be: >> draft-ietf-rohc-rfc3095bis-profiles-00.txt, >> please name the upcoming initial individual draft similarly: >> draft-pelletier-rohc-rfc3095bis-profiles-00.txt >=20 > I don't really agree with this, as the RoHCv2 profiles are > not meant to replace the already existing profiles, but > rather to create an updated variants without replacing the > current profiles. In other words, new profile numbers should > be issued by IANA. So I don't see the RoHCv2 profiles draft having > the "bis" in its name. There is no single meaning associated with the use of "bis". The two new documents specify an updated version of the protocol specified by 3095, therefore it can be called a bis to 3095. Of course it will have to be allocated new profile numbers since it is not identical to 3095, but that is irrelevant when it comes to naming.=20 For this working group, bis is a proper name for the work we are now doing producing an updated version of our current protocol(s). This work will thus be captured in three documents with consistent names: - draft-ietf-rohc-rfc3095bis-improvements - draft-ietf-rohc-rfc3095bis-framework - draft-ietf-rohc-rfc3095bis-profiles /L-E =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc