Subject: RE: [rohc] Default decompression algorithms

From: "Abbie Barbir"<[email-masked]>
Date: Wed, 20 Feb 2002 11:20:03 -0500

> -----Original Message-----
> From: Price, Richard [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 10:12 AM
> To: 'Lars-Erik Jonsson (EPL)'; Conroy, Lawrence (SMTP)
> Cc: [email-masked]
> Subject: [rohc] Default decompression algorithms
> 
> 

------------------- SNIP SNIP

> Making one or more of these well-known algorithms mandatory at the
> decompressor doesn't contradict the UDVM approach because the 
> decision on
> which algorithm to use (or whether to download a new one) is 
> still made by
> the compressor. So we have a "win-win" situation; the 
> compressor downloads
> a new algorithm to the decompressor when it judges the 
> overall performance
> to be better than using one of the existing algorithms.
> 

-------------- 
Can you suggest how this would be done (implemented) from the compressor
end.

abbie

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 21 Feb 2002 10:25:07 +0100

Richard,

> So for the wireless environment 3GPP will be
> able to choose their own list of mandatory and optional algorithms.

Yes, they use to do it that way, but why should WE make any algorithm
mandatory at the decompressor. As you say yourself, the decompressor
can announce what resources it has, and the compressor decides what to
use based on that, but the decompressor does not have to announce any
available algorithms. If it does not, the compressor just do not have
any other choice than to download its own algorithm.

> I would be very happy to include both approaches in the SigComp
> solution and leave the decision on which to use to the compressor.

Simple and well defined solutions with few options are usually
preferable when making standards, at least in the IETF. 

/L-E

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

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 21 Feb 2002 14:21:42 -0000

> To me it seems the current draft is about twice as complex as it needs to be.
> We need real time to fix all the small details in that complexity.
> Complexity grows at least with some polynomial of the feature set.

Hi Carsten,

Is the additional complexity that you are worried about mainly due to the
technical mechanisms of the draft, or the informative explanation of how the
mechanisms can be used? There is quite a bit of the latter, and whilst it is
very useful for implementers it is non-normative and could easily be omitted
from the RFC.

Perhaps we could shrink the size of the SigComp RFC by moving some of the text
into a "SigComp implementer's guide" draft? This text could remain at draft
status for now; we could put it into the SigComp RFC at a later stage (perhaps
when we reach Draft Standard).

If you believe that any technical mechanism could be omitted from SigComp
without reducing the performance too badly then please let us know!

> If we want to finish in time, we need to focus on removing, not about
> adding.
> 
> Since anybody can "profile" SigComp to include certain state ab initio, I
> would like to propose that we end this discussion now.

As you mention above, the mechanisms needed to provide algorithm negotiation
are available already as part of the state reference mechanism. However, the
reason that Lawrence began this discussion in the first place is as follows:

[LWC]  We have the facilities within SigComp to minimise or even remove the need
for downloads, so the whacky contrib or three to the CN1 meeting is just a case
of this group and CN1 being slightly out of phase.

The "wacky contributions" were in fact proposals to add a separate algorithm
negotiation mechanism externally to SigComp, despite the fact that one is already
available within SigComp itself. More text is required somewhere to make this
clear, although it is an implementation issue only and so does not need to be
standardised as part of the base RFC for now.

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 21 Feb 2002 17:56:50 -0000

> decompressor doesn't contradict the UDVM approach because the decision on 
> which algorithm to use (or whether to download a new one) is still made by 
> the compressor. So we have a "win-win" situation; the compressor downloads 
> a new algorithm to the decompressor when it judges the overall performance 
-------------- 
> Can you suggest how this would be done (implemented) from the compressor end. 
> abbie

Hi,

There are quite a few issues that the compressor will need to consider when
judging overall performance, including some or all of the following metrics:

1   Compression ratio

2   Processing efficiency

3   Memory efficiency

4   Implementation effort

5   IPR considerations

The IPR considerations are particularly important, since encumbered algorithms
tend to substantially outperform unencumbered algorithms in terms of metrics
1, 2, and 3.

So if a compressor has licensed the bytecode for an encumbered algorithm, it
is usually preferable to download this bytecode to a decompressor that does
not support the encumbered algorithm, rather than picking one of the weaker
unencumbered algorithms already available at the decompressor.

Regards,

Richard Price

---

From: Scott Bradner <[email-masked]>
Date: Thu, 21 Feb 2002 13:26:46 -0500 (EST)

> The IPR considerations are particularly important

note that RFCs do not contain specific IPR information - just a pointer
to the on-line repository

the basic reason is that the RFC is forever but the IPR information 
can (and will) change over time - an IPR snapshot in a RFC could be
quite misleading as to the actual IPR state at the time that someone
was reading the RFC

Scott

---

From: "Abbie Barbir"<[email-masked]>
Date: Thu, 21 Feb 2002 13:31:22 -0500

Richard,

Thanks for the responce.
I am aware of what the compressor need to do. However, your remark states

"the compressor downloads a new algorithm to the decompressor when it 
judges the overall performance to be better than using one of the existing 
algorithms"

>From an implementation point of view, 
1. are you saying that the compressor must/should keep a list that relates
 a device's algorithm with the compression ratio etc that it could achieve?
2. Or the compressor will first attempt to compress using the algorithm that
is avilable at the decompressor and then it realize that i can get better
compression if this xyz algorithm is used, so what will do 
  - try to remember that for the next message
  - decide to go ahead with this message and then download a new algorithm 
    to the UDVM

Definitly other options could be used. The point here, is that the above
statement
can be hard to implement in the field.

abbie

> Sent: Thursday, February 21, 2002 12:57 PM
> To: Barbir, Abbie [CAR:1A00:EXCH]; 'Lars-Erik Jonsson (EPL)'; Conroy,
> Lawrence (SMTP)
> Cc: [email-masked]
> Subject: RE: [rohc] Default decompression algorithms
> 
>

---

From: "Abbie Barbir"<[email-masked]>
Date: Fri, 22 Feb 2002 07:26:54 -0500

> From: Lars-Erik Jonsson (EPL) 
> [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 2:55 AM
> To: 'Price, Richard'
> Cc: [email-masked]
> Subject: [rohc] RE: Default decompression algorithms
> 
> 
> Richard,
> 
> > > LEJ: why should WE make any algorithm
> > >      mandatory at the decompressor.
> > 
> > RP: We shouldn't - in my opinion it would be a mistake for the 
> >     ROHC Working Group to do more than standardise the algorithms
> >     themselves. The final decision on whether algorithms are
> >     mandatory or optional should be made in the context of a
> >     particular application.
> 
> OK, then we do not have a disagreement. This was not clear from
> your previous posting:
> 
sounds good, standadise the algorithm themselevs and let the application
specify the default one.

ps: what would this imply in terms of interoperability testing and
compliance from this WG. This include:
1. UDVM compliance
2. Actual algorithm compliance

abbie

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Mon, 25 Feb 2002 08:47:31 +0100

> > >     ROHC Working Group to do more than standardize the algorithms 
> AB: sounds good, standardize the algorithm themselves and let the
> application specify the default one. 

[LEJ: ] By defining the UDVM-solution, we do not have to standardize any algorithms. We may describe example UDVM algorithms, but from our point of
view the algorithms themselves do not have to be standardized.

/L-E

---

From: [email-masked]
Date: Tue, 26 Feb 2002 09:28:34 -0600

> > - We need a mechanism to allow the decompressor to announce the
> > decompression code it can locally generate or it already
> > has (see below). It seems most people agree with my proposal:
> > http://www.cdt.luth.se/robhc/msg03642.html. That's all we need.
> 
> I'm not sure it is exactly clear what this message proposes.
> Who is going to write this up?

I'll write it up.

Zhigang

---

From: [email-masked]
Date: Tue, 26 Feb 2002 10:57:26 -0600

> From: ext Dr. Carsten Bormann [mailto:[email-masked]]
> Sent: February 26, 2002 10:28 AM
> To: Miguel A. Garcia; Liu Zhigang.C (NRC/Dallas)
> Cc: [email-masked]
> Subject: RE: [rohc] RE: Default decompression algorithms
> 
> 
> > I also agree with the requirement whereby a decompressor informs
> > the compressor of the algorythms that are already uploaded, and
> > therefore, don't need to be uploaded again. This is just to
> > save bandwidth over the air interface and avoid unneeded uploads.
> > I think this is a very valid requirement.
> 
> How many algorithms are there going to be in the cache of a typical
> decompressor?

That depends on the cache size. For a mobile, it should be a 
small number. For the network-side decompressor, it anyway has
to store decompression codes corresponding to each active compressor
(in mobiles). So, it may has a large number of codes.

> What is the cost of supplying this information?

The announcement message overhead = n * 6, where n is the number 
of decompression codes and 6 is the number of bytes for a hash. 
Let s be the average code size and p(n) be the probability of 
a hit. Then the savings = (s - 6n) * p(n).

Of course, the RTT as you mentioned is also a cost. But if the
announcement can be piggybacked on the reply from the decompressor
during the negotiation of the use of SigComp, it is not an extra
cost anymore. (But I don't know if the message sequence Hans 
outlined sometime ago is still valid.)

BR,
Zhigang