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

From: "Price, Richard" <[email-masked]>
Date: Tue, 5 Nov 2002 14:46:58 -0000

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

> -----Original Message-----
> From: Ghyslain Pelletier [mailto:[email-masked]]
> Sent: Tuesday, November 05, 2002 10:30 AM
> To: [email-masked]; [email-masked]
> Subject: [rohc] draft-saifullah-rohc-tcp-early-comp*-00.txt
> 
> 
> Hi Yousuf,
> 
> Regarding draft-saifullah-rohc-tcp-early-compression-00.txt and
> draft-saifullah-rohc-tcp-early-comp-in-gprs-00.txt:
> 
> My current understanding is that these drafts:
> 
> 1) describes the ground principles behind the idea of populating a
>    ROHC-TCP decompressor context prior to the use of ROHC IR packets.
> 2) defines a generic approach ("Early Compression Enabler") that uses
>    out-of-band mechanisms ("Early Compression mechanisms"), as well
>    as the necessary additions required within the profile definition
>    for the in-band part of the approach. This may be used to populate
>    a ROHC-TCP decompression context prior to in-band initialization.
> 3) provides an example when applied in a gprs system.
> 
> How well these drafts relates to the ROHC WG is somewhat unclear to me,
> for the following reasons:
> 
> - I believe that the idea behind reusing information already present
>   at the decompressor side is already part of the currently ongoing
>   work around context replication in draft-ietf-rohc-tcp-03.txt
> - I believe that out-of-band mechanisms for improving the
>   performance of ROHC should not be addresed by the WG, but
>   within the respective applicable standardization bodies of the
>   related technology.
> 
> Once out-of-band mechanisms are not considered by the WG, what is left
> are the in-band additions. The in-band functionality necessary to
> identify reusable information already present at the decompressor is
> already part of the context replication work for ROHC-TCP. Therefore I
> am not sure if these drafts bring new useful information to this WG.
> 
> Best regards,
> 
> /Ghyslain Pelletier
> Wireless IP Optimizations
> AWARE - Advanced Wireless Algorithm Research
> Ericsson Research, Corporate Unit
> Ericsson AB
> Luleå, Sweden
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Ghyslain Pelletier <[email-masked]>
Date: Tue, 05 Nov 2002 18:29:51 +0100

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