Subject: [Sip] RE: [rohc] signaling message compression - speed up

From: "Price, Richard" <[email-masked]>
Date: Mon, 3 Sep 2001 17:56:03 +0100

> The schedule of this work item (from what I heard) is
> quite aggressive. To achieve that, should we start to
> piece good ideas from different proposals together and 
> create a new draft? From there, we can proceed with a 
> few cycles to refine it.

From the discussions so far, I believe that the following changes
could usefully be made to the current UDPComp draft:

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/
>

---

From: Hans Hannu <[email-masked]>
Date: Tue, 04 Sep 2001 10:46:22 +0200

Hi,

Comments inline.

> Any volunteers to have a closer look at context management?

I'll take a look at this. I believe that there are text in both ROGER and
SCRIBE that can be reused for this.

By the way, as context management has a little bit to do with
acknowledgement of messages. Do you believe that we need an explicit
acknowledgement scheme as describe in ROGER and SCRIBE? - I do so, in order
to maintain generality of the scheme.

> misordering and dropped packets.

Yes. Also if the scheme encounters a hop in the sequence numbers, it should
not stop updating the "dynamic dictionary" in order to use more information
in the compression/decompression process.

> implementation decision?

If both compressor and decompressor have this kind of information, I do not
see a problem with this, but maybe I'm missing something.

>How would we go about standardising

What should we standardize? The kind information in this user-specific
dictionary (u-sd)? or the format of the u-sd? Or how to exchange the
information?

> context selection a local implementation decision at the

As long as we use the corresponding context at the decompressor. Do you see
another way on how to identify the context?

> > 3) Shared mode. Should help, especially for SIP messages.

Yes, this is something I believe we should have.

BR
/Hans H

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip