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

From: "Qian Zhang (MSR)" <[email-masked]>
Date: Thu, 7 Nov 2002 20:21:05 +0800

Dear all,

We would like to give some comments on this issue.
1. To our understanding, we can treat Yousuf's idea as the extension for the "context replication" scheme in ROHC-TCP. In general, we can regard that ROHC-TCP solution is explicitly introduced for replicating the context that had already established using header compression protocol. Maybe we can call it as "intra-protocol replication". We can treat Yousuf's idea as replicating the context that had established by other protocols (or mechanisms). Maybe we can call it as "inter-protocol replication". That is to say, we can cover this in "context replication" part of work.

2. Although some performance improvement can obtained by using Yousuf's idea, what worry us is that we may need to have specific profile to boost the performance in each particular environments, GPRS, IEEE802.11a/b, cdma1x, cdma1xEx-Do, etc. That may not be a good way to pursue.

3. Actually we can support this early-compression feature using the context replication scheme now in ROHC-TCP. If the compressor can make sure that some certain fields in the context had already been established in the decompressor side, we can simply set those fields as replicable field in IR-REPLICATE packet. As for how to let the compressor have this type of confidence and how to let the decompressor know where to replicate the context can be treated as implementation issues, which not need to be standardized.
In other words, we can support this type of feature by simply extends the "context replication" part of work.

Best regards,

Qian and Hongbin

-----Original Message-----
From: Ghyslain Pelletier [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2002 1:30 AM
To: Price, Richard; [email-masked]
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
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc