Subject: RE: [rohc] draft-saifullah-rohc-tcp-early-comp*-00.txt

From: [email-masked]
Date: Tue, 5 Nov 2002 12:17:21 -0600

Ghyslain,
Your main point is that we should not discuss Early Compression Enabler in ROHC WG. I would disagree with this. First, I am not proposing any link layer out of band mechanism. I am proposing an Enabler not a mechanism, which provides compression and  ROHC WG is the place to build compression protocols. It is in accordance with the ROHC TCP requirements. Please send me specific comments on draf-saifullah-rohc-tcp-early-compression.txt and please do not mix my second informative draft on GPRS with Early Compression Enabler proposal.

Let me try to give an example from existing ROHC work, http://www.ietf.org/rfc/rfc3242.txt?number=3242 (A Link-Layer Assisted Profile for IP/UDP/RTP). This RFC is defined for link-layer assisted profile. Early Compression Enabler does not even limit itself for link specific mechanism, please see the RSVP example as another early compression mechanism example in the next para.

In this para I will answer the main points from your email:
- Supporting out-of-band mechanisms
I am not askiing ROHC-WG to support any out-of-band mechanism. I have specifically mentioned this in my draft. I have also clarified this in my last email. There is no use in repeating myself in this email again. 
- Context replication, as agreed by the WG
Early Compression does not compete with context replication. I have mentioned the differences in my previous emails, please refer to them. I saw last response from Richard where he understood that the early compression provides a more general mechanism for allowing certain TCP/IP fields to be signalled outband, and this could incorporate context replication. So I don't understand the confusion. Also, I have checked the archive and I didn't see where the WG has agreed on the context replication protocol. Please provide me the reference.
- Relevance of the "Early comp*" drafts to the ROHC WG
You are confusing Early Compression Enabler with an Early Compression Mechanism. I have also explained this in my last email that I have published second draft, draft-saifullah-rohc-tcp-early-comp-in-gprs-00.txt, as an informative draft and not as proposal for protocol changes. GPRS is not the only example where early compression can be used. Also early compression mechanism could be RSVP signaling. RSVP signaling contains the following header fields, which can again be used for compression purposes:
·	Source and destination address
·	Source and destination port
·	Flow Label (IPv6)
·	Protocol ID

In an RSVP connection, it is usually not possible to compress the packet headers, as RSVP relies on the existence of the header fields above for identifying the packets which belong to the connection in each node on the path. However, it is possible that a radio connection or a tunnel is a part of this path, and RSVP may be used to set up this connection. The information taken from the RSVP signaling could improve the efficiency of the header compression in the same way as the mentioned in the informative draft using GPRS as example.

Cheers,
Yousuf

-----Original Message-----
From: ext Ghyslain Pelletier [mailto:[email-masked]]
Sent: 05 November, 2002 11:30 AM
To: Price, Richard; Saifullah Yousuf (NRC/Dallas)
Cc: [email-masked]; Lars-Erik Jonsson (EPL)
Subject: Re: [rohc] draft-saifullah-rohc-tcp-early-comp*-00.txt

Richard and Yusuf,

Yusuf, it is correct that draft-ietf-rohc-tcp-03.txt is not yet
available. I have submitted it on Friday and it should be available
soon. However, I refer to it as it is a WG document for which the
content is the combination of draft-ietf-rohc-tcp-02.txt and the mailing
list discussions, which are both known.

Richard, I am not sure that I agree that reusing a context already
existing in both a compressor and a decompressor should be considered
"outband information". This is simply information that has previously
been exchanged inband between two entities.

I think we have to be very careful about allowing ourselves to design
the ROHC-TCP profile with "hooks" towards technology-specific
out-of-band mechanisms. I will try to explain my position more clearly:

- Supporting out-of-band mechanisms
-----------------------------------
Out-of-band mechanisms are technology-specific. Not all links have these
mechanisms either. The possibility that there might exist such a
mechanism does not make it generic to any link. My understanding is that
support for out-of-band mechanisms are outside the scope of ROHC-TCP and
of the context replication mechanism.

Alternatively, the relevance of addressing this in this WG could be
stated as two separate questions:

1) Should a profile be designed with the assumption that the systems in
which it is applied defines, implements and uses a PDP context
activation procedure (GPRS), or a flow mapping procedure (CDMA2000) or
another type of out-of-band parameter exchange that could include values
of fields to be compressed?

2) Should the protocol defined for performing header compression define
the hooks to the link-specific procedures (or should it rather be the
other way around?)

- Context replication, as agreed by the WG
------------------------------------------
The context replication mechanism of ROHC-TCP will allow the reuse of
information already present at both endpoints, by providing an inband
reference to a base context. This is all considered to happen in-band.

- Relevance of the "Early comp*" drafts to the ROHC WG
------------------------------------------------------
My understanding of these drafts is that it is suggested that ROHC-TCP
include specific support for arbitrary out-of-band mechanisms that
install a context prior to initialization.

To reuse information exchanged out-of-band, I would rather suggest that
it should be up to the specific system where header compression is
applied to standardize and implement such optimization, not the
opposite.

For example, the out-of-band procedure could first establish the desired
parameters, and this could be used to establish a base context on both
side. The out-of-band exchange should then be used to agree on this
optimization as well as on an inband reference to a base context (eg a
CID) to provide the hook between the out-of-band procedure and the
ROHC-TCP context replication mechanism. Then the context replication
mechanism could simply use this reference as usual with an IR-Replicate
packet. The ROHC-TCP profile need not (and should not) consider anything
more than context replication, and do not need "generic" support for any
link-specific out-of-band mechanism.

What these drafts are trying to achieve is in my opinion only relevant
to the implementations of the systems where header compression will be
applied, not to the definition of a ROHC profile (and thus not to this
WG).

Best regards,

/Ghyslain Pelletier
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Luleå, Sweden

"Price, Richard" wrote:
> 
> Hi,
> 
> One area where these drafts may influence our work on the TCP
> compression scheme is in the design of the packet formats.
> 
> The current "TCP/IP Field Behavior" draft considers the case where
> the outband information for setting up a new context is provided from
> an existing context. In this case fields such as the IP version and
> the IP addresses are not shared because it is not expected that they
> can be derived from existing contexts. The resulting IR-REPLICATE
> packet will therefore send these fields in full.
> 
> However, in the specific case discussed in <draft-saifullah-rohc-tcp-
> early-comp-in-gprs-00.txt> the IP version and IP destination address
> fields can be obtained outband. To support this within the TCP
> compression scheme we'd need to take into account the possibility
> that these fields might be available at the start of a new context
> (and hence create an IR-REPLICATE packet that can optionally avoid
> sending the fields if possible).
> 
> Any opinions on whether this behaviour is worth taking into account in
> the IR-REPLICATE packet? The proposed mechanism can save just over 16
> bytes when it is employed, with a small cost (~1 bit per IR-REPLICATE
> packet) for signalling that the mechanism is not being used.
> 
> Regards,
> 
> Richard
>
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Ghyslain Pelletier <[email-masked]>
Date: Tue, 05 Nov 2002 20:16:12 +0100

Yousuf,

My main points from the beginning are that the following is unclear to
me:

* Why mix context replication with "Early Compression Enabler"?
* Why supporting out-of-band mechanism within the ROHC-TCP profile
  would be within scope and would even be needed?
* Why can one not achieve "Early Compression" using context
  replication along with the out-of-band mechanism of the specific
  link technology, instead of requiring the opposite?

That's all. Obviously, it is up to the WG to make the decision regarding
the way forward with these documents. It seems that there is a
discussion ongoing, which I have decided to be part of, and I simply
wanted to provide my two cents - which I will repeat later again in this
mail because I still cannot find my answers.

> You are confusing Early Compression Enabler with an
> Early Compression Mechanism.

The "Early Compression Enabler" is additions to a ROHC-TCP profile in
the forms of compressor/decompressor logic, packet formats and feedback
formats. Example of "Early Compression Mechanisms" include PDP Context
Activation, RSVP signalling, Flow Mapping etc. Is this the correct
understanding?

I still think that we should be careful with such proposal like "Early
Compression Enabler". ROHC-TCP is meant to compress TCP/IP, and the
suggested approach of "Early Compression Enabler" seems to expand its
scope beyond this WG into providing hooks for potential technology
specific optimizations ("Early Compression Mechanisms"). The hooks I am
referring to here are not the specific out-of-band mechanism(s), but the
additions found in draft-saifullah-rohc-tcp-early-compression.txt.

ROHC-TCP should maintain a clear scope, and in particular when it is
related to such optimizations. Concepts behind such as the context
replication mechanism have been discussed and agreed on the basis that
it reuses exisiting header compression entities and contexts.

I also still think that the possible existence of out-of band mechanisms
should not be relevant to the definition of the ROHC-TCP profile, and
that the optimization that is suggested seems rather relevant to other
standardization bodies, eg they seem mostly related to optimize ROHC-TCP
implementations in various systems.

> I am not asking ROHC-WG to support any out-of-band mechanism.

I have kept that in mind all along. The proposal however does require a
ROHC-TCP profile to include additional compressor/decompressor logic,
packet formats and feedback formats to support out-of-band mechanisms.
Is this the correct understanding?

The intent with my comments is to provide feedback only pertaining to
the idea being the "Early Compression Enabler". I have tried to use the
reference to the other draft as a mean to show that "Early Compression
Enabler" is meant to accomodate link-layer specific mechanisms. I am not
referring to it by fear that the point is to standardize an "Early
Compression Mechanism" here in this WG. The use of RSVP to populate a
context is not new to me, as it was discussed in 3GPP2/TSG-P some months
ago and is still actual as part of one of their optimization solution
for RTP traffic.

However as I said previously, RSVP signalling and PDP context activation
may not be used everytime/everywhere ROHC-TCP is used.

> I saw last response from Richard where he understood that the early
> compression provides a more general mechanism for allowing certain
> TCP/IP fields to be signalled outband, and this could incorporate
> context replication. So I don't understand the confusion. 

There is no confusion, simply different opinions.
Hopefully by this mail this is clearer.

Best regards,

/Ghyslain