RE: draft-ietf-ippcp-lzs-02.txt

Robert Friend <rfriend@hifn.com> Fri, 21 November 1997 22:13 UTC

Return-Path: rfriend@hifn.com
Received: from beasley.cisco.com (mailgate-sj-2.cisco.com [171.69.2.135]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01050 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 21 Nov 1997 14:13:01 -0800 (PST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id OAA23757 for <ippcp@external.cisco.com>; Fri, 21 Nov 1997 14:13:02 -0800 (PST)
Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id OAA04383 for <ippcp@external.cisco.com>; Fri, 21 Nov 1997 14:13:01 -0800 (PST)
Received: from mailman.hifn.com(206.19.120.66) by proxy2.cisco.com via smap (V2.0) id xma004275; Fri, 21 Nov 97 22:12:40 GMT
Received: by mailman.hifn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BCF687.96D4FD50@mailman.hifn.com>; Fri, 21 Nov 1997 14:13:07 -0800
Message-ID: <c=US%a=_%p=HIFN_Inc.%l=TBU1-971121221305Z-1736@mailman.hifn.com>
From: Robert Friend <rfriend@hifn.com>
To: 'Roy Pereira' <rpereira@TimeStep.com>
Cc: 'IPPCP' <ippcp@external.cisco.com>
Subject: RE: draft-ietf-ippcp-lzs-02.txt
Date: Fri, 21 Nov 1997 14:13:05 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Roy,

Thanks for the feedback.

What I learned in the PPPEXT WG was that each algorithm has fields that
are particular to that algorithm (e.g. Reset-REQ/Reset-ACK or the
headers of datagrams).  What was needed there was a general picture in
the base protocol and specific pictures for each algorithm.

My first concern is that the Flags field may be the same way here.
There may be algorithms in the future that may make individual use of
the Flags field (e.g. stateful compression for other than IP).  My
second concern is that the reader of these documents know the exact
position of the payload and other headers relative IPComp header exist.
At this point there is no such picture in the base protocol document.
Ideas?

On the limits of compression: I believe the min side is system dependent
and data dependent.  It costs a certain amount of latency to compress
the datagram to see if compression is working.  That latency is system
dependent.  Also, the latency is a better investment if you get a good
compression ratio.  I don't know how we could put such a number in this
standard.  Comments?  On the max side, isn't the MTU the limit?  I must
admit that I don't understand the utility of specifying this
information?  Please help me out here.  I suppose we could put a generic
statement about the system may want to consider implementing some upper
and lower bounds of datagram size to compress.  What do you think about
that?

Regards,
_____________________________________________________________

Robert C. Friend              Hi/fn
Applications Engineering      5973 Avenida Encinas, Suite 110
voice: (760) 827-4542         Carlsbad, CA 92008
FAX:   (760) 827-4577         email: rfriend@hifn.com

>-----Original Message-----
>From:	Roy Pereira [SMTP:rpereira@TimeStep.com]
>Sent:	Friday, November 21, 1997 1:05 PM
>To:	Robert Friend; 'IPPCP'
>Subject:	RE: draft-ietf-ippcp-lzs-02.txt
>
>I have comments.
>
>I don't like the idea of placing the protocol header in this document.
>There has to be a clear abstraction between the two levels of documents.
> We have already learned this in IPSec.  Thus I would like to see
>section 2.3 disapear or be changed to indicate what goes inside the
>Payload Data field. (ie. compressed data).
>
>I would also like to see some limits on when compression should be sued
>and not be used.  
>     "When using LZS don't compress under 300 bytes or over 1.5 Mb"
>
>
>On Thursday, November 20, 1997 8:15 PM, Robert Friend
>[SMTP:rfriend@hifn.com] wrote:
>> Hi Guys,
>> 
>> I'm reading ietf mail getting itchy fingers.  I haven't received any
>> comments on the -02 draft other than Avrum saying it "looks good".  If I
>> don't get any more comments by tommorrow morning eastern time, I'll send
>> this draft to "Internet-Drafts" tommorrow morning pacific time.
>> 
>> Thanks,
>> _____________________________________________________________
>> 
>> Robert C. Friend              Hi/fn
>> Applications Engineering      5973 Avenida Encinas, Suite 110
>> voice: (760) 827-4542         Carlsbad, CA 92008
>> FAX:   (760) 827-4577         email: rfriend@hifn.com
>>