Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed)

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Sat, 5 Jul 2003 19:20:44 +0200

> >   I find motivations to add an additional state for CR 
> >   somewhat thin, also in relation to the limited amount
> >   of logic attached to it
> 
> In general, I believe that the purpose of the compressor state
> machine is to provide information needed by a context to
> decide which packet format to use when compressing a header.
> Different states allow a different range of packet formats to
> be used. 

I rather see the compression states as a pedagogic way of
describing how the compression process works. Note that
RFC 3095 does not define 1-to-1 mappings between packet
types and compression states, nor is the compression and
decompression states the same. I do not believe we should
extend the state set just because of context replication,
that would rather be something to consider in implementation.

/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Cho Chia Yuan" <[email-masked]>
Date: Tue, 8 Jul 2003 15:07:14 +0800

Hi Ghyslain,

I have been working on Context Replication in ROHC-TCP and I already
have a working implementation of CR in ROHC-TCP. Therefore, I hope that
I can be of help to the ROHC effort.

There are some points that I seek to discuss and address from the
ROHC-CR draft and discussions:

Section 3.2.1:
"For simplicity, contexts with the same Source-IP and/or Destination-IP
may be considered as replicable contexts, and the most recent one should
be selected as the candidate to be replicated."

The recommendation on 'same Source-IP and/or Destination-IP' can be
broken down into three permutations.

I have tested CR based on contexts with (i)same source-IP and same
destination-IP and (ii)same source-IP but different destination-IP but
not on (iii)same destination-IP but different source-IP, as I have
doubts that there would be significant redundancy between packets from
different sources. (i) and (ii) works fine with (i) being especially
efficient, but would (iii) work?

Concerning the feasibility of adding an 'IR-REPLICATE' state into the
compressor state set:

  'I find motivations to add an additional state for CR somewhat thin,
  also in relation to the limited amount of logic attached to it and
  because ROHC-CR does not define a complete state machine. This issue
  in my opinion is only a matter of how to document logic to support
  the IR-REPLICATE, it is not about the logic itself (for which we
  seem to have agreement). I'd prefer instead that we make an attempt
  in ensuring that the text for both the compressor and decompressor
  logic is clear when using the IR-REPLICATE.'

I agree with the logic for CR. Because there is always a possibility of
the context not being present at the decompressor, the compressor would
always have to remember that it has sent IR-REPLICATE because it has to
switch to IR instead when it receives STATIC-NACK. I guess this memory
is inherent if CR is to be used. The issue is then whether you call this
a separate 'state' or not. I have a suggestion: the ROHC can encapsulate
the IR-REPLICATE 'sub-state' inside the IR state instead, since the
possibility of using CR itself is up to implementation.

However, state-machines do make logics much clearer, and ROHC-CR can do
it be defining the IR-REPLICATE 'sub-state' in relation to the IR
'sub-state' within the ROHC IR state black box.

Finally, I have some current work which may be of interest to ROHC-CR.

(i)Statistical studies on the efficiency gains achievable through
context replication.

As predicted, it improves the efficiency of short-lived TCP flows
tremendously. The justification for CR to be used is that the majority
of TCP flows are smaller than ~10kB, the region where gains through CR
are significant.

(ii)Studying TCP/IP field behaviour between different TCP flows
statistically to exploit the inter-flow redundancy in CR. The inter-flow
delta has a larger variance than intra-flow delta and thus for CR to
work without sending most fields uncompressed, the compression
specification must be fine-tuned to suit the inter-flow field behaviour.

The qualitative analysis on inter-flow behaviour in TCP-BEH was
tremendously helpful, but due to the large variance of inter-flow
behaviour, there is a need to determine this behaviour quantitatively.

(iii)Studying the max number of contexts to keep for CR
This is an implementation specific parameter. The problem is that CR
requires a larger number of contexts to be kept. This aims to optimize
between memory requirements and context replication gains.

Do let me know if the above helps :)

Chia Yuan, Cho
Institute of Infocommunication Research
National University of Singapore