From pppext-bounces@ietf.org Fri Jul 07 16:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyxAM-0005bC-P8; Fri, 07 Jul 2006 16:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysY3-0003km-3n for pppext@ietf.org; Fri, 07 Jul 2006 11:47:19 -0400 Received: from eclipse.eti.pg.gda.pl ([153.19.48.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysY1-0007nb-LT for pppext@ietf.org; Fri, 07 Jul 2006 11:47:19 -0400 Received: from [127.0.0.1] (daemon@piorun.ds.pg.gda.pl [153.19.208.8]) (authenticated bits=0) by eclipse.eti.pg.gda.pl (8.12.11/8.12.11) with ESMTP id k67FkrBk005075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jul 2006 17:47:07 +0200 (CEST) Message-ID: <44AE81B7.1000203@eclipse.eti.pg.gda.pl> Date: Fri, 07 Jul 2006 17:45:59 +0200 From: Janusz Jurski User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: pppext@ietf.org, jjurski@eti.pg.gda.pl Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.4 (eclipse.eti.pg.gda.pl [153.19.48.52]); Fri, 07 Jul 2006 17:47:08 +0200 (CEST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on eclipse.eti.pg.gda.pl X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Fri, 07 Jul 2006 16:43:09 -0400 Cc: Subject: [Pppext] draft-jurski-pppext-iphc-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Hi All, I have submitted the following Internet draft: http://www.ietf.org/internet-drafts/draft-jurski-pppext-iphc-00.txt. The document adds an extension to IP Header Compression negotiation for PPP. The abstract of the document is as follows: This document extends RFC 3544 (which extended its predecessor, RFC 2509) by specifying additional negotiation options to PPP Control Protocols for IPv4 and IPv6 (see RFC 1332, RFC 2472). The negotiation options specified in RFC 2509 defined an all-or-nothing strategy for applying header compression: peers were assumed to support compression for any combination of headers. RFC 3544 refined that strategy to make it possible to negotiate header compression for only TCP or only non-TCP packets. The current document further refines the strategy by also making it possible to negotiate header compression for only particular combinations of headers or header types. I would like to discuss the proposal / request your comments. Note that the most of the document is copied from RFC 3544 (and RFC 2509). A new suboption is defined in Section 2.5. Section 5.2 explains the reasons for this new suboption and discusses the advantages and disadvantages. Kind regards, Janusz _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 20 16:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fSw-0007K0-QQ; Thu, 20 Jul 2006 16:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fSw-0007Jv-6h for pppext@ietf.org; Thu, 20 Jul 2006 16:49:50 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fSt-0003Hi-EU for pppext@ietf.org; Thu, 20 Jul 2006 16:49:50 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6KKnkxj014452 for ; Thu, 20 Jul 2006 13:49:46 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k6KKnjiX022264 for ; Thu, 20 Jul 2006 16:49:46 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k6KKp5p6024813; Thu, 20 Jul 2006 16:51:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.6+Sun/8.13.6/Submit) id k6KKp5uj024810; Thu, 20 Jul 2006 16:51:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17599.60600.868765.668357@gargle.gargle.HOWL> Date: Thu, 20 Jul 2006 16:51:04 -0400 From: James Carlson To: Janusz Jurski Subject: Re: [Pppext] draft-jurski-pppext-iphc-00.txt In-Reply-To: Janusz Jurski's message of 7 July 2006 17:45:59 References: <44AE81B7.1000203@eclipse.eti.pg.gda.pl> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Janusz Jurski writes: > I would like to discuss the proposal / request your comments. Note that > the most of the document is copied from RFC 3544 (and RFC 2509). A new > suboption is defined in Section 2.5. Section 5.2 explains the reasons > for this new suboption and discusses the advantages and disadvantages. I don't quite see why this must obsolete RFC 3544. It looks to me like a compatible extension to that RFC. There are overlaps in the functionality -- in the 'A', 'B', and 'C' bits. This adds complexity, but for no apparent reason. Why do this? Doesn't the existing suboption work well enough? Why must everyone end up with two different ways of invoking those features? The lack of dynamic adaptation seems like a flaw to me. Just because a node expects one mix of traffic at one point in time is no good reason to suppose that the traffic mix will not be different later. The original negotiation options were posed in terms of system limits rather than traffic behavior for that reason. In particular, this section: Note that, while the compressor could use heuristics to determine the most efficient way to compress flows, the decompressor may be in a much better position to know the expected traffic type. For example, makes no sense to me. The compressor and decompressor have almost *exactly* the same set of information. It's the set of packets passing over the link. One thing the compressor has that the decompressor doesn't is the instantaneous queue depth. I can see nothing that the decompressor has that the compressor does not. A compressor that notices that it's wasting compression state on short-lived exchanges could alter its behavior over time so that it doesn't do that. Having the decompressor "guess" that its exchanges in the future will be short and then disabling compression in advance seems fragile. Perhaps it'd be better to write a paper about the best way for a compressor to use a limited number of contexts when the traffic mix is unknown in advance. But those are possibly nits. The big problem here is in the motivation. Why is it exactly that the existing MAX_HEADER and *_SPACE variables aren't sufficient to limit resource consumption? Besides bytes of storage required (already controlled by the existing parameters), what do extension headers have to do with complexity on the decompressor side? How does failing to compress some UDP headers when RTP is running help? If you're really constrained but still need compression, why wouldn't you set the number of contexts to 1, and the maximum header size as small as practical (say, 64 octets)? It looks to me like the motivation in section 5.2 switches back and forth between memory and CPU power. Clearly, the existing options already give you a chance (and a seemingly adequate one) to control memory consumption. Moreover, the proposed new feature does _NOT_ add anything that will help to further reduce memory consumption by adding any new limits to the required storage. So, the real rationale must be CPU power, not "gigabytes" of space. When the memory arguments are dispensed with, though, there seems to be little to support the idea; it becomes just another tiny-CPU-too- much-code argument. I don't think that permanently burdening everyone else (until the end of time) to support a temporary design problem is a good use of the standards process. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext