Subject: IPPCP working group minutes

From: Naganand Doraswamy <[email-masked]>
Date: Fri, 29 Aug 1997 14:02:59 -0400

Folks,

This is a slightly more formal version of the minutes. I need to send it to
the IETF by the 1st of Sept. If anybody feels I have misinterpreted
something, please speak now.

IETF/Munich August 13, 1:00pm
=============================

Chair: Naganand Dorswamy 
Scribed by: Roy Pereira

The IPPCP working group met for the first time in Munich. There were
approximatly 35 attendees. The agenda in the meeting was to discuss the
charter and resolve some architecture and protocol issues.

The discussions on the charter did not change the charter that was approved
by the IESG. The primary goal of the working group is to define a
compression protocol. The primary goal is to make it work in the context of
IPsec. However, the working group will define the protocol so that it is
generic enough to work even when IPsec is not being used. As discussed in
the charter, we will support both manual and dynamic negotiation of
compression parameters such as algorithm. This working group does not deal
with issues of compression at the transport layer.

There were three presentations.

Bob Monsour
-----------
Bob presented the combined architecture draft: draft-ietf-ippcp-arch-00.txt
which raised the following issues
1. Should we support per session based compression?
2. Should we support stateful or stateless compression?
3. Should we mandate whether compression should be used if it increases the
size of payload and whether we should include the compression header in
that case.
4. If used with a key mgmt protocol such as ISAKMP, should we negotiate
compression as an attribute or as a protocol?

There were two proposals for performing comrpession and this presentation
highlighted the advantages and disadvantages of the two approaches-
ip-in-ip or a separate protocol header. These issues have been discussed in
the architecture draft as well.

Matt Thomas
-----------

Matt Thomas presented his draft although the protocol header that he
presented was different than what was specified in his draft. The protocol
header was then changed during the course of the meeting. The final
protocol header that will be proposed to the working group is shown below.
  +-------------+-------------+-----------------------------+
  | Next Header |    Flags    | Compression Parameter Index |
  +-------------+-------------+-----------------------------+

Avram Shacham
-------------
Avram presented his draft draft-ietf-ippcp-ipcomp-00.txt. He discussed when
and why it makes sense to compress packets before performing compression.
It was mentioned during presentation it makes more sense to compress over
slow links. 

Performance increase of 1.7 for 28.8k
Performance decrease of 0.7 for 10M

There were questions asked about whether it makes sense to compress packets
even on fast links if the encryption algorithm is slow.  There is no data
to make any statments on this.

URL of presentation: www.tgv.cisco.com/public/shacham/ipcomp.ppt

Resolutions
------------

The following were some of the things the working group agreed on.

1.  IPCOMP must be done before IPSec
2.  The compression should be stateless
3.  The compression, if desired, should be on the granularity of a session.
4.  If the compression expands the packet, then compression SHOULD not be
performed and in that case the compression header SHOULD not be sent in the
packet.
5.  Compression should be implemented as a separate protocol.

Open Issues
------
1.  Architecture document must state that all algorithm documents must
state thresholds for whether compression should be performed.
2.  We need to finalize the IPCOMP protocol (ie. bits of the wire).
3.  Location of IPCOMP within IPv6 must be defined in architecture
document.
4.  Should a CPI failure send ICMP error messages?
5.  Should we have static SA that are defined by predefined public CPI
values?
6.  Should IPCOMP be a "MUST used" before AH/ESP/frag/hop-by-hop
7.  Should we mandate any one particular algorithm as mandatory to implement?

Next Steps
-----------
If possible, compress the protocol document and the architecture document
into one and publish this document as soon as possible. This will enable us
to decide on the header format so that people can implement this protocol.
The open issues needs to be addressed in this document.

It was a common consensus that this working group should be done with its
commitments by the Washington IETF. 
--Naganand

-----------------------------------------------------------------
Naganand Doraswamy				(508)916-1323 (O)
Bay Architecture Lab				(508)670-8153 (Fax)
3 Federal St, Mail Stop BL3-04
Billerica, MA 01821