Subject: RE: A suggested change to the architecture doc (already)

From: Avram Shacham <[email-masked]>
Date: Wed, 30 Jul 1997 09:19:45 -0700

At 11:20 AM 7/30/97 -0400, Roy Pereira wrote:
>>I am assuming, under Matt's scenario, that the CPI will ALWAYS be present
>>if compression was negotiated. But there will be cases where, due to small
>>packets or an uncompressible datagram, that the sender does not want to
>>compress. In those cases doesn't the next header field still have to be
>>IPCOMP so that the receiver can remove the CPI?
>
>But I don't think that is necessary.  Compression isn't critical as is
>Security.  When we negotiate Security, both parties must use that
>transform or the packet is invalid.  But when both parties negotiate
>Compression, either party does not have to compress that packet.  This
>would not violate any rules.  Thus when a packet can't be compressed,
>then we really don't need to waste space by adding any compression
>header.  
>

One more argument against the requirement to ALWAYS include CPI:

Consider file transfer of a large ZIP-ed file, where packets size is MTU.
These packets don't compress and therefore are sent as-is. Adding 8-byte CPI
to mark that the packets are not compressed will bring the packet size to
MTU _plus_ 8-bytes and will force packet fragmentation. The only way to
avoid such unnecessary packet fragmentation is for IPComp to _always_ reduce
MTU by sizeof(CPI), similar to ESP/AH process. I'd vote against such
inefficiency in the protocol.

avram

BTW, I suggest we move such basic discussions back to the mailing-list.