From rohc-bounces@ietf.org Tue Apr 03 01:10:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYbHw-0003zr-62; Tue, 03 Apr 2007 01:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYbHt-0003zj-SJ for rohc@ietf.org; Tue, 03 Apr 2007 01:10:33 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYbHq-00063e-GH for rohc@ietf.org; Tue, 03 Apr 2007 01:10:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1C55C90034 for ; Tue, 3 Apr 2007 01:10:27 -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 03222-15 for ; Tue, 3 Apr 2007 01:10:22 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 3 Apr 2007 01:10:22 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 01:10:22 -0400 Received: from bsarkar ([10.6.7.222]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 10:40:07 +0530 From: Biplab Sarkar To: rohc@ietf.org Organization: Starent Networks Date: Tue, 03 Apr 2007 10:40:10 +0530 Message-Id: <1175577011.8987.25.camel@bsarkar-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 03 Apr 2007 05:10:07.0741 (UTC) FILETIME=[58C4F2D0:01C775AE] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [rohc] ROHC feedback X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2057016989==" Errors-To: rohc-bounces@ietf.org --===============2057016989== Content-Type: multipart/alternative; boundary="=-GvyhTRdePkYF1x+4UCz8" --=-GvyhTRdePkYF1x+4UCz8 Content-Type: text/plain Content-Transfer-Encoding: 7bit All, I believe one of the short comings of the ROHC feedback mechanism is that it might get wrongly interpreted at the other end. Since the CID might get reused because of the limitation imposed my MAX_CID. And I have seen a roundabout delay of about 4-5 packets typically. So, its very likely going to get mis-interpreted. There should be some restrictions on the re-use of CID. Thanks Biplab ++++++++++++++++++++++++++ Starent Networks India Pvt Ltd. 5th Floor,Surya Chambers, No 124 Murgeshpalya, Airport Road Bangalore, 560017 Ph: +91-80-40109512 ++++++++++++++++++++++++++ --=-GvyhTRdePkYF1x+4UCz8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit All,

I believe one of the short comings of the ROHC feedback mechanism is that it might get wrongly interpreted at the other end. Since the CID might get reused because of the limitation imposed my MAX_CID. And I have seen a roundabout delay of about 4-5 packets typically. So, its very likely going to get mis-interpreted. There should be some restrictions on the re-use of CID.

Thanks
Biplab

++++++++++++++++++++++++++
Starent Networks India Pvt Ltd.
5th Floor,Surya Chambers, No 124
Murgeshpalya, Airport Road
Bangalore, 560017
Ph: +91-80-40109512
++++++++++++++++++++++++++

--=-GvyhTRdePkYF1x+4UCz8-- --===============2057016989== 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 --===============2057016989==-- From rohc-bounces@ietf.org Tue Apr 03 02:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYcbk-0004ts-Vd; Tue, 03 Apr 2007 02:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYcbj-0004tj-Si for rohc@ietf.org; Tue, 03 Apr 2007 02:35:07 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYcbe-00012Z-Aj for rohc@ietf.org; Tue, 03 Apr 2007 02:35:07 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8AC3D21532; Tue, 3 Apr 2007 08:34:51 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-83-4611f58b35fb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 782692056C; Tue, 3 Apr 2007 08:34:51 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:34: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] ROHC feedback Date: Tue, 3 Apr 2007 08:34:50 +0200 Message-ID: In-Reply-To: <1175577011.8987.25.camel@bsarkar-desktop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] ROHC feedback Thread-Index: Acd1romymv6Vv/CDSS6sP8AVRDgfxQACAzwQ From: "Kristofer Sandlund $LU/EAB$" To: , X-OriginalArrivalTime: 03 Apr 2007 06:34:51.0145 (UTC) FILETIME=[2EB6D790:01C775BA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Biplab, first of all, do you think the provisions in section 7 of rfc4815 are=20 insufficient for context reuse? I think there are already quite a bit of restrictions that handle the harmful cases (and the only cases where there is ever any "danger" would be R-mode related and I think that's covered by 4815). For U/O-mode: - Getting a NACK that was meant for the "old" context doesn't do any damage, it just decreases the compression efficiency for a=20 short while. - A compressor is never *required* to do anything with ACKs, and they are=20 only there in order to give guidance to the compressor so it *can* try to improve its compression efficiency. Getting an ACK for the old context *can* of course be a bit more dangerous if the compressor uses ACKs to move to a higher compression state (but see also section 8.10 of rfc4815). But since the compressor can know that it has recently been re-used it should just decide to not use the ACKs for that purpose. If you don't agree with the above, could you describe in what situation you think that misinterpreted feedback actually breaks the compression=20 or where the provisions of rfc4815 are insufficient. BR, Kristofer Biplab Sarkar wrote on den 3 april 2007 07:10 : > All, >=20 > I believe one of the short comings of the ROHC feedback > mechanism is that it might get wrongly interpreted at the > other end. Since the CID might get reused because of the > limitation imposed my MAX_CID. And I have seen a roundabout > delay of about 4-5 packets typically. So, its very likely > going to get mis-interpreted. There should be some > restrictions on the re-use of CID. >=20 > Thanks > Biplab >=20 >=20 >=20 > ++++++++++++++++++++++++++ > Starent Networks India Pvt Ltd. > 5th Floor,Surya Chambers, No 124 > Murgeshpalya, Airport Road > Bangalore, 560017 > Ph: +91-80-40109512 > ++++++++++++++++++++++++++ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 03 04:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeMg-0006QI-3z; Tue, 03 Apr 2007 04:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeMe-0006Pg-Rg for rohc@ietf.org; Tue, 03 Apr 2007 04:27:40 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYeMa-0000Pu-OT for rohc@ietf.org; Tue, 03 Apr 2007 04:27:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id EE23A90034 for ; Tue, 3 Apr 2007 04:27:32 -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 08025-02 for ; Tue, 3 Apr 2007 04:27:28 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 3 Apr 2007 04:27:28 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 04:27:28 -0400 Received: from bsarkar ([10.6.7.222]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 13:57:21 +0530 Subject: RE: [rohc] ROHC feedback From: Biplab Sarkar To: "Kristofer Sandlund (LU/EAB)" In-Reply-To: References: Organization: Starent Networks Date: Tue, 03 Apr 2007 13:57:24 +0530 Message-Id: <1175588844.8987.32.camel@bsarkar-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 03 Apr 2007 08:27:21.0134 (UTC) FILETIME=[E6056CE0:01C775C9] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394841791==" Errors-To: rohc-bounces@ietf.org --===============0394841791== Content-Type: multipart/alternative; boundary="=-ksc0CEAgBFKGCF07Zbkb" --=-ksc0CEAgBFKGCF07Zbkb Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Kristofer, The problem that I see is for U/O mode. The NACK comes for a SN of the previous profile. Since the profile was reused, it matched to some thing else and gave an in-efficient compression. Its really not dangerous, rather in-efficient. The transit delay of packets adds more to it. One should be discouraged to use MAX_CID=0 to avoid these type of problems. Thanks Biplan On Tue, 2007-04-03 at 08:34 +0200, Kristofer Sandlund (LU/EAB) wrote: > Hi Biplab, > > first of all, do you think the provisions in section 7 of rfc4815 are > insufficient for context reuse? I think there are already quite a bit of > restrictions that handle the harmful cases (and the only cases where > there > is ever any "danger" would be R-mode related and I think that's covered > by 4815). > > For U/O-mode: > - Getting a NACK that was meant for the "old" context doesn't > do any damage, it just decreases the compression efficiency for a > short while. > - A compressor is never *required* to do anything with ACKs, and they > are > only there in order to give guidance to the compressor so it > *can* try to improve its compression efficiency. Getting an ACK for the > old context *can* of course be a bit more dangerous if the compressor > uses ACKs to move to a higher compression state (but see also section > 8.10 > of rfc4815). But since the compressor can know that it has recently been > re-used it should just decide to not use the ACKs for that purpose. > > If you don't agree with the above, could you describe in what situation > you think that misinterpreted feedback actually breaks the compression > or where the provisions of rfc4815 are insufficient. > > BR, > Kristofer > > > Biplab Sarkar wrote on den 3 april > 2007 07:10 : > > > All, > > > > I believe one of the short comings of the ROHC feedback > > mechanism is that it might get wrongly interpreted at the > > other end. Since the CID might get reused because of the > > limitation imposed my MAX_CID. And I have seen a roundabout > > delay of about 4-5 packets typically. So, its very likely > > going to get mis-interpreted. There should be some > > restrictions on the re-use of CID. > > > > Thanks > > Biplab > > > > > > > > ++++++++++++++++++++++++++ > > Starent Networks India Pvt Ltd. > > 5th Floor,Surya Chambers, No 124 > > Murgeshpalya, Airport Road > > Bangalore, 560017 > > Ph: +91-80-40109512 > > ++++++++++++++++++++++++++ ++++++++++++++++++++++++++ Starent Networks India Pvt Ltd. 5th Floor,Surya Chambers, No 124 Murgeshpalya, Airport Road Bangalore, 560017 Ph: +91-80-40109512 ++++++++++++++++++++++++++ --=-ksc0CEAgBFKGCF07Zbkb Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Kristofer,

The problem that I see is for U/O mode. The NACK comes for a SN of the previous profile. Since the profile was reused, it matched to some thing else and gave an in-efficient compression. Its really not dangerous, rather in-efficient. The transit delay of packets adds more to it. One should be discouraged to use MAX_CID=0 to avoid these type of problems.

Thanks
Biplan

On Tue, 2007-04-03 at 08:34 +0200, Kristofer Sandlund (LU/EAB) wrote:

Hi Biplab,

first of all, do you think the provisions in section 7 of rfc4815 are 
insufficient for context reuse? I think there are already quite a bit of
restrictions that handle the harmful cases (and the only cases where
there
is ever any "danger" would be R-mode related and I think that's covered
by 4815).

For U/O-mode:
- Getting a NACK that was meant for the "old" context doesn't
do any damage, it just decreases the compression efficiency for a 
short while.
- A compressor is never *required* to do anything with ACKs, and they
are 
only there in order to give guidance to the compressor so it
*can* try to improve its compression efficiency. Getting an ACK for the
old context *can* of course be a bit more dangerous if the compressor
uses ACKs to move to a higher compression state (but see also section
8.10
of rfc4815). But since the compressor can know that it has recently been
re-used it should just decide to not use the ACKs for that purpose.

If you don't agree with the above, could you describe in what situation
you think that misinterpreted feedback actually breaks the compression 
or where the provisions of rfc4815 are insufficient.

BR,
    Kristofer


Biplab Sarkar <mailto:bsarkar@starentnetworks.com> wrote on den 3 april
2007 07:10 :

> All,
> 
> I believe one of the short comings of the ROHC feedback
> mechanism is that it might get wrongly interpreted at the
> other end. Since the CID might get reused because of the
> limitation imposed my MAX_CID. And I have seen a roundabout
> delay of about 4-5 packets typically. So, its very likely
> going to get mis-interpreted. There should be some
> restrictions on the re-use of CID.
> 
> Thanks
> Biplab
> 
> 
> 
> ++++++++++++++++++++++++++
> Starent Networks India Pvt Ltd.
> 5th Floor,Surya Chambers, No 124
> Murgeshpalya, Airport Road
> Bangalore, 560017
> Ph: +91-80-40109512
> ++++++++++++++++++++++++++

++++++++++++++++++++++++++
Starent Networks India Pvt Ltd.
5th Floor,Surya Chambers, No 124
Murgeshpalya, Airport Road
Bangalore, 560017
Ph: +91-80-40109512
++++++++++++++++++++++++++

--=-ksc0CEAgBFKGCF07Zbkb-- --===============0394841791== 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 --===============0394841791==-- From rohc-bounces@ietf.org Tue Apr 03 05:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYev2-0006b7-Gp; Tue, 03 Apr 2007 05:03:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYev1-0006b0-PJ for rohc@ietf.org; Tue, 03 Apr 2007 05:03:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYeuj-0000YQ-V6 for rohc@ietf.org; Tue, 03 Apr 2007 05:03:11 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 025F821601; Tue, 3 Apr 2007 11:02:31 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-a7-46121826108f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DAD8420FEE; Tue, 3 Apr 2007 11:02:30 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:02: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC feedback Date: Tue, 3 Apr 2007 11:02:29 +0200 Message-ID: In-Reply-To: <1175588844.8987.32.camel$0001@bsarkar-desktop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] ROHC feedback Thread-Index: Acd1yepLUt/nW4tVRkSBXRCCZawzAQAAfYZg From: "Kristofer Sandlund $LU/EAB$" To: X-OriginalArrivalTime: 03 Apr 2007 09:02:30.0723 (UTC) FILETIME=[CF6F2930:01C775CE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 Biplab, what you're describing is not a problem with any of the ROHC specifications. If this is something that happens frequently, then you have configured your deployment with a MAX_CID lower than the number of flows that are active on the channel (this is what rfc2507 refers to as CID thrashing). So, I don't think there's anything to be said within this WG other than that depoyments should be configured with a "large enough" MAX_CID to handle the expected number of paralell flows (then if that means MAX_CID=3D0 or if it means MAX_CID=3D10000, that's up to the deployment to decide). BR, Kristofer Biplab Sarkar wrote on den 3 april 2007 10:27 : > Hi Kristofer, >=20 > The problem that I see is for U/O mode. The NACK comes for a > SN of the previous profile. Since the profile was reused, it > matched to some thing else and gave an in-efficient > compression. Its really not dangerous, rather in-efficient. > The transit delay of packets adds more to it. One should be > discouraged to use MAX_CID=3D0 to avoid these type of problems. >=20 > Thanks > Biplan >=20 >=20 > On Tue, 2007-04-03 at 08:34 +0200, Kristofer Sandlund (LU/EAB) wrote: >=20 >=20 > Hi Biplab, >=20 > first of all, do you think the provisions in section 7 > of rfc4815 are > insufficient for context reuse? I think there are > already quite a bit of > restrictions that handle the harmful cases (and the > only cases where > there > is ever any "danger" would be R-mode related and I > think that's covered > by 4815). >=20 > For U/O-mode: > - Getting a NACK that was meant for the "old" context doesn't > do any damage, it just decreases the compression > efficiency for a > short while. > - A compressor is never *required* to do anything with > ACKs, and they > are > only there in order to give guidance to the compressor so it > *can* try to improve its compression efficiency. > Getting an ACK for the > old context *can* of course be a bit more dangerous if > the compressor > uses ACKs to move to a higher compression state (but > see also section > 8.10 > of rfc4815). But since the compressor can know that it > has recently been > re-used it should just decide to not use the ACKs for > that purpose. >=20 > If you don't agree with the above, could you describe > in what situation > you think that misinterpreted feedback actually breaks > the compression > or where the provisions of rfc4815 are insufficient. >=20 > BR, > Kristofer >=20 >=20 > Biplab Sarkar > wrote on den 3 april > 2007 07:10 : >=20 > > All, > > > > I believe one of the short comings of the ROHC feedback > > mechanism is that it might get wrongly interpreted at the > > other end. Since the CID might get reused because of the > > limitation imposed my MAX_CID. And I have seen a roundabout > > delay of about 4-5 packets typically. So, its very likely > > going to get mis-interpreted. There should be some > > restrictions on the re-use of CID. > > > > Thanks > > Biplab > > > > > > > > ++++++++++++++++++++++++++ > > Starent Networks India Pvt Ltd. > > 5th Floor,Surya Chambers, No 124 > > Murgeshpalya, Airport Road > > Bangalore, 560017 > > Ph: +91-80-40109512 > > ++++++++++++++++++++++++++ >=20 > ++++++++++++++++++++++++++ > Starent Networks India Pvt Ltd. > 5th Floor,Surya Chambers, No 124 > Murgeshpalya, Airport Road > Bangalore, 560017 > Ph: +91-80-40109512 > ++++++++++++++++++++++++++ >=20 >=20 >=20 >=20 > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information > transmitted may not be used to create or change any > contractual obligations of Starent Networks, Corp. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon this e-mail and its > attachments by persons or entities other than the intended > recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of > this message and any attachments without reading or > disclosing their contents. Thank you." _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 03 06:32:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgJ9-0001QU-BF; Tue, 03 Apr 2007 06:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgJ8-0001Pg-23 for rohc@ietf.org; Tue, 03 Apr 2007 06:32:10 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgIq-00079x-Co for rohc@ietf.org; Tue, 03 Apr 2007 06:32:10 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l33AVgrX012518; Tue, 3 Apr 2007 12:31:43 +0200 (CEST) In-Reply-To: <1175588844.8987.32.camel@bsarkar-desktop> References: <1175588844.8987.32.camel@bsarkar-desktop> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=MACINTOSH; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Carsten Bormann Subject: Re: [rohc] ROHC feedback Date: Tue, 3 Apr 2007 12:31:33 +0200 To: bsarkar@starentnetworks.com X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Apr 03 2007, at 10:27, Biplab Sarkar wrote: > One should be discouraged to use MAX_CID=3D0 Indeed (why would one want to do this?). Of course, the interesting thing with starting a new CID for a new =20 call that immediately follows a preceding call is that you are then =20 stuck with that (non-zero) CID for the duration of that flow (or =20 until you IR context CID=3D0 with the same flow, which also is a bit =20 inefficient). CR would help a bit here (but the CR packets still =20 aren't second order). All quality of implementation issues, nothing to standardize here. (Except that the full-byte penalty for CID=AD0 is somewhat unfortunate, =20= but we didn't have a way to come up with a smaller penalty.) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 03 07:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgyV-0001VW-EZ; Tue, 03 Apr 2007 07:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgxr-0000dC-TS for rohc@ietf.org; Tue, 03 Apr 2007 07:14:15 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgtP-0002Nd-48 for rohc@ietf.org; Tue, 03 Apr 2007 07:09:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2EC0890040 for ; Tue, 3 Apr 2007 07:09:35 -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 10618-09 for ; Tue, 3 Apr 2007 07:09:31 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 3 Apr 2007 07:09:31 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 07:09:31 -0400 Received: from bsarkar ([10.6.7.222]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 16:39:21 +0530 Subject: Re: [rohc] ROHC feedback From: Biplab Sarkar To: Carsten Bormann In-Reply-To: References: <1175588844.8987.32.camel@bsarkar-desktop> Organization: Starent Networks Date: Tue, 03 Apr 2007 16:39:27 +0530 Message-Id: <1175598567.8987.55.camel@bsarkar-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 03 Apr 2007 11:09:21.0763 (UTC) FILETIME=[87F7B330:01C775E0] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0120738487==" Errors-To: rohc-bounces@ietf.org --===============0120738487== Content-Type: multipart/alternative; boundary="=-Xo606mCF7m/qkHWAdAIJ" --=-Xo606mCF7m/qkHWAdAIJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carsten, People seems to like the idea of MAX_CID=3D0 just for avoiding the one-byte overhead. For VoIP traffic people are to picky about it. I was thinking of allocating CIDs efficiently by giving CID=3D0 to the packets which are highly probable. Thanks Biplab On Tue, 2007-04-03 at 12:31 +0200, Carsten Bormann wrote: > On Apr 03 2007, at 10:27, Biplab Sarkar wrote: >=20 > > One should be discouraged to use MAX_CID=3D0 >=20 > Indeed (why would one want to do this?). >=20 > Of course, the interesting thing with starting a new CID for a new =20 > call that immediately follows a preceding call is that you are then =20 > stuck with that (non-zero) CID for the duration of that flow (or =20 > until you IR context CID=3D0 with the same flow, which also is a bit =20 > inefficient). CR would help a bit here (but the CR packets still =20 > aren't second order). >=20 > All quality of implementation issues, nothing to standardize here. > (Except that the full-byte penalty for CID=E2=89=A00 is somewhat unfortun= ate, =20 > but we didn't have a way to come up with a smaller penalty.) >=20 > Gruesse, Carsten >=20 ++++++++++++++++++++++++++ Starent Networks India Pvt Ltd. 5th Floor,Surya Chambers, No 124 Murgeshpalya, Airport Road Bangalore, 560017 Ph: +91-80-40109512 ++++++++++++++++++++++++++ --=-Xo606mCF7m/qkHWAdAIJ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Carsten,

People seems to like the idea of MAX_CID=0 just for avoiding the one-byte overhead. For VoIP traffic people are to picky about it. I was thinking of allocating CIDs efficiently by giving CID=0 to the packets which are highly probable.

Thanks
Biplab

On Tue, 2007-04-03 at 12:31 +0200, Carsten Bormann wrote:

On Apr 03 2007, at 10:27, Biplab Sarkar wrote:

> One should be discouraged to use MAX_CID=0

Indeed (why would one want to do this?).

Of course, the interesting thing with starting a new CID for a new  
call that immediately follows a preceding call is that you are then  
stuck with that (non-zero) CID for the duration of that flow (or  
until you IR context CID=0 with the same flow, which also is a bit  
inefficient).  CR would help a bit here (but the CR packets still  
aren't second order).

All quality of implementation issues, nothing to standardize here.
(Except that the full-byte penalty for CID≠0 is somewhat unfortunate,  
but we didn't have a way to come up with a smaller penalty.)

Gruesse, Carsten

++++++++++++++++++++++++++
Starent Networks India Pvt Ltd.
5th Floor,Surya Chambers, No 124
Murgeshpalya, Airport Road
Bangalore, 560017
Ph: +91-80-40109512
++++++++++++++++++++++++++

--=-Xo606mCF7m/qkHWAdAIJ-- --===============0120738487== 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 --===============0120738487==-- From rohc-bounces@ietf.org Tue Apr 10 05:07:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCJN-0005x5-P1; Tue, 10 Apr 2007 05:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCJM-0005ww-K3 for rohc@ietf.org; Tue, 10 Apr 2007 05:06:48 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbCJL-0007mt-3p for rohc@ietf.org; Tue, 10 Apr 2007 05:06:48 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8DB5220789; Tue, 10 Apr 2007 11:06:42 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-54-461b53a2a1af Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6A9BA2051A; Tue, 10 Apr 2007 11:06:42 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:06:42 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:06:41 +0200 Message-ID: <461B53AA.808@ericsson.com> Date: Tue, 10 Apr 2007 11:06:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [rohc] AD comments on draft-ietf-rohc-sigcomp-sip-05 References: <460BA763.4020703@ericsson.com> <460BAFDC.1000801@nokia.com> <460BBAB8.3010906@ericsson.com> <460BBC39.8020601@nokia.com> <460BC810.8020509@ericsson.com> In-Reply-To: <460BC810.8020509@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 09:06:41.0500 (UTC) FILETIME=[8DCCF1C0:01C77B4F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Miguel Garcia , 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, I am still waiting for a response on my second question. /Magnus Magnus Westerlund skrev: > Miguel Garcia skrev: >> >> >> Magnus Westerlund wrote: >> > Miguel Garcia skrev: >> >> >> >> >> >> Magnus Westerlund wrote: >> >> > Hi, >> >> > >> >> > I have now reviewed the SigComp draft and a have a few comments. >> >> > >> >> > 1. Section 3. >> >> > >> >> > Additionally, it must support the SIP/SDP static dictionary, as >> >> > specified in [RFC3485], and the mechanism for discovering >> SigComp >> >> > support at the SIP layer, as specified in [RFC3486]. >> >> > >> >> > Shouldn't the "must" in the above sentence be "MUST"? >> >> >> >> That "MUST" is already written in RFC 3485 and RFC 3486, >> respectively, >> >> so, in my opinion, the "must" is correct, especially since the text >> >> refers to both canonical specifications RFC 3485 and RFC 3486. >> >> >> > >> > Now you get me confused. Isn't this document the one intended to be >> the >> > root document for anyone implementing sigcomp for SIP? In that case it >> > seems necessary for this document to have a normative statement saying >> > that you shall implement RFC 3485 and RFC 3486. It doesn't matter if >> > these document are within themselves saying what feature to implement. >> > >> >> Yes and no. I don't think it makes sense to have two equal normative >> statements in different documents, a technique commonly known as >> overspecifying. Remember that no matter whether you have >> draft-ietf-rohc-sigcomp-sip-05 or not, the MUST implement RFC 3485 and >> 3486 remain in their respective documents. >> >> Thus, I am fine with the current wording. It could be rewording in >> different words, for example: "Notice that RFC 3485 and RC 3486 already >> mandate the implementations.... " But this is just a matter of taste. >> > > Okay, based on that wording in RFC 3485 and 3486 can't be changed I am > fine with the current wording. > > What about question 2? > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > 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 > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- 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 Tue Apr 10 05:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCTu-0002xq-FZ; Tue, 10 Apr 2007 05:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCTs-0002vc-9j for rohc@ietf.org; Tue, 10 Apr 2007 05:17:40 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbCS4-0000Zv-VQ for rohc@ietf.org; Tue, 10 Apr 2007 05:16:04 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.13.2) with ESMTP id l3A9FZmP003227; Tue, 10 Apr 2007 11:15:36 +0200 (CEST) In-Reply-To: <460BA763.4020703@ericsson.com> References: <460BA763.4020703@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] AD comments on draft-ietf-rohc-sigcomp-sip-05 Date: Tue, 10 Apr 2007 12:15:33 +0300 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > 2. Section 5. Last paragraph: > > Should it for any reason not be desirable to set up > more than one TCP connection to a SIP implementation, but the > flexibility to send both compressed and uncompressed SIP > messages be > required, the compressor can set up a SigComp-structured connection > and send any uncompressed SIP messages using the well-known shim > header. > > What is "SigComp-structured connection"? A reference to where this > is specified might be a good idea. This is referring to a TCP connection that uses SigComp (as opposed to raw SIP). The "structured" here pertains to the fact that SigComp imposes a (record marking) structure, but this is not really the point; the point is that this is a TCP connection carrying SigComp compressed messages, but saying "compressed" is a bit confusing as we are talking about uncompressed messages carried in a SigComp compression shim. Maybe just s/-structured// to solve this little semantic problem. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 11 08:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbc9G-00031D-6R; Wed, 11 Apr 2007 08:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbc9E-000317-Uu for rohc@ietf.org; Wed, 11 Apr 2007 08:42:04 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbc97-0001iM-BU for rohc@ietf.org; Wed, 11 Apr 2007 08:42:04 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BF6022055C; Wed, 11 Apr 2007 14:41:52 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-a8-461cd790fee8 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AAD1B20415; Wed, 11 Apr 2007 14:41:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 14:41:52 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 14:41:52 +0200 Message-ID: <461CD790.2050402@ericsson.com> Date: Wed, 11 Apr 2007 14:41:52 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] AD comments on draft-ietf-rohc-sigcomp-sip-05 References: <460BA763.4020703@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 12:41:52.0190 (UTC) FILETIME=[C795A5E0:01C77C36] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Carsten Bormann skrev: > > > > 2. Section 5. Last paragraph: > > > > Should it for any reason not be desirable to set up > > more than one TCP connection to a SIP implementation, but the > > flexibility to send both compressed and uncompressed SIP > > messages be > > required, the compressor can set up a SigComp-structured connection > > and send any uncompressed SIP messages using the well-known shim > > header. > > > > What is "SigComp-structured connection"? A reference to where this > > is specified might be a good idea. > > This is referring to a TCP connection that uses SigComp (as opposed > to raw SIP). > The "structured" here pertains to the fact that SigComp imposes a > (record marking) structure, but this is not really the point; the > point is that this is a TCP connection carrying SigComp compressed > messages, but saying "compressed" is a bit confusing as we are > talking about uncompressed messages carried in a SigComp compression > shim. > > Maybe just s/-structured// to solve this little semantic problem. > Yes, that is likely to reduce confusion that the reader has missed something. Please submit an updated version. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- 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