No Subject

Dictionary structure:

Should be able to handle a wide range of compression algorithms
(in particular SIP-aware algorithms like EPIC, TCCB and
template-based compression, as the current overhead for these
schemes is large). The protocol overhead should be minimal, as
should the complexity of the dictionary structure.

My current favourite is the digraph dictionary, which is simpler
than a tree structure and more general to boot. I could provide
some text on this if it is needed.

Context management:

Currently the context is identified by IP address and port, and is
initialised empty. However this does not at present allow us to use
the following:

  -  User-specific dictionary
  -  Cross session dictionary
  -  Shared dictionary

Perhaps we could make the context selection a local implementation
decision at the compressor (as per RFC 3095)? This would generalise
what we can keep in the dictionary across sessions without needing
additional standardisation.

Any volunteers to have a closer look at context management?

Robustness:

We need to check that any new mechanism is robust against
misordering and dropped packets.

If possible, it would be nice to release a working group draft for
signalling compression over the next few weeks. Do we need the
updated charter in order to do this?

I have included some comments and a few additional points inline.

Regards,

Richard P

> Three weeks has past since the last IETF meeting. Is there
> any news on the official change of ROHC charter to include 
> the work of signaling compression?
> 
> Specifically, besides the current discussion on Huffman 
> encoding and tree structured dictionary, we should also
> consider the following:
> 
> 1) User specific dictionary (seems every agreed during
> the discussion)

Having a user-specific dictionary gives a big boost to the
compression ratio (80% better for EPIC, 40% better for
TCCB etc.), so we should clearly think about how to capture
this performance benefit. How does it square with the
UDPComp idea of making the compression algorithm a local
implementation decision? How would we go about standardising
a user-specific dictionary within this framework?

> 
> 2) Maintain dynamic dictionary across session. It is 
> reasonable not to throw away the synchronized dictionary.

This is another clear win in terms of performance, especially
if we aren't using preconfigured static dictionaries. I
believe that the "context" is currently defined by a pair of
IP addresses and ports. Instead, perhaps we could just make
context selection a local implementation decision at the
compressor?

> 
> 3) Shared mode. Should help, especially for SIP messages.
> 
> 4) Make sure the dictionary synchronization is robust
> against packet loss/misordering. Complexity may be
> affected by dictionary structure.

The main difficulty here is ensuring that the dictionary
can continue to be used while entries are in the process of
being added or modified. Any dictionary structure we use
must be able to handle this.

> 
> 5) Concurrency issue (re dictionary updates) in shared
> mode.
> 
> 6) Make sure a misordered message can still be decompressed
> correctly (related to 4 and 5 but a different issue)
> 
> 7) Protocol is generic. E.g. if tree structured dictionary
> is used, should make sure Lempel-Ziv is still possible and
> not penalized. Also, should not depend on SIP-specific
> knowledge (although is should work well compressing SIP).
> 
> 8) Template encoding. Very useful for simple low-end terminals, 
> which are probably the majority during the introduction
> of SIP to cellular.

Template encoding is a compression algorithm, so the dictionary
structure should be chosen such that template-based encoding is
supported.

> 
> 9) Anything else?

We might need to introduce pre-downloaded static dictionaries (very
useful for reducing the working memory requirements, as well as
for unidirectional links where it is more difficult to dynamically
modify the dictionary).

> 
> Above are just some tools we already have and can be used
> to tackle the problem. Most of them are simple. It would be 
> good if we put them together and then tune the protocol to 
> reach a good tradeoff between compression efficiency, 
> complexity and flexibility.
> 
> Comments?
> 
> BR,
> Zhigang
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 

--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit

The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------InterScan_NT_MIME_Boundary--

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip