Subject: RE: [rohc] RE: Default decompression algorithms

From: [email-masked]
Date: Mon, 25 Feb 2002 19:09:16 -0600

Folks,

Let's conclude this issue. We've spent too much time on this.

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

- Let's not call them "default" or "mandatory", at least not here
in IETF. The choice is the compressor's. If its choice happens
to be popular, then it can avoid sending it over the air using
above mechanism. But that's it. Nothing more.

- Documentation of "well-known" decompression code is second 
priority to other things. It can be done either in IETF or 3GPP. 
But let's finish other more important things (e.g. security, state
management) first in this WG.

- The issue is not even about documented code. The above mechanism
is useful when multiple mobiles use the same code. Once the
decompressor acquire one copy of the code from one mobile, there 
is no need to download the code later when another mobiles talk to 
the same decompressor in the network. 

BR,
Zhigang

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

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 26 Feb 2002 02:41:06 +0100

> Let's conclude this issue. We've spent too much time on this.

Good point.

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

> above mechanism. But that's it. Nothing more.

If it somehow gets a message from the decompressor first.
I don't think we have agreement on the need for this additional expensive
round trip yet.
(Of course, in a specific environment, that knowledge may come from a
different protocol.)

> management) first in this WG.

I think we do have consensus on this point.
This work is not standards-track, we don't have to (nor should) agree on
anything.
(Work on specific decompressors is needed for validation, though.)

> the same decompressor in the network.

If the mobile somehow gets a message from the decompressor first.

Gruesse, Carsten

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 26 Feb 2002 18:14:52 +0200

Hi:

I am aligned with Zhigang. I believe there is not need to define
a "default" or "mandatory" algorythm. If other organizations, 
like 3GPP, want to define such an algorythm, that is fine, but
please, don't do it here in the IETF.

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.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 26 Feb 2002 17:28:21 +0100

> I think this is a very valid requirement.

How many algorithms are there going to be in the cache of a typical
decompressor?
What is the cost of supplying this information?
Explain how this computes.

Gruesse, Carsten

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 26 Feb 2002 18:52:47 +0200

Hi:

I will try to explain the scenario I am thinking of, and then try
to answer your questions.

Typically a proxy will be serving many users, let's say, thousands.
As such, when a terminal starts the SigComp procedures towards the
proxy, it might happen that the proxy has got a copy of the algorithm,
because the same algorithm was already uploaded by another terminal.

If this is the case, the decompressor at the proxy should announce that
those algorithms that are already uploaded, and therefore, don't require
to be uploaded once more.

If it happens that the terminal wants to use a different algorithm that
is not already in use at that proxy, then the terminal will know that
the algorithm is not uploaded and the terminal needs to uploaded.

You asked how many algorithms are going to be in the cache of a 
typical decompressor, and that question is related to how many users
a proxy can support simultaneously, and how many different algorithms.
In other words, it is implementation dependent, and the answer to the
question does not have an impact on the standardization in Rohc.

The cost of supplying the information: I don't have a strong opinion
on how this can be done, but I will refer to examples that are working
today in other protocols. For instance, RTP decided to use a profile
for Audio/Video codecs (RFC 1890). Known codecs are assigned a Payload
Type in RTP. So Payload Type 0 means PCM u-law codec, Payload 8 means 
PCM A-law codec. 

In SigComp, we could take the same approach, in a way that we define
a standard way to refer to known algorithms. The decompressor, in
the SigComp Capabilities Announcements would indicate the list of 
algorithms that are already uploaded (in a similar way of how SDP,
RFC 2327 negotiates codecs).

If there are other opinions how to fulfill the requirement, I would 
like to listen to them.

/Miguel

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 26 Feb 2002 22:47:32 +0100

Miguel,

thanks for the detailed explanation.

> question does not have an impact on the standardization in Rohc.

Well, the technical parameters in the expected operating range typically do
have an influence on standardization, in particular for a standard the only
purpose of which is optimization.

BTW, I don't believe there is an appreciable technical limit to the number
of algorithms a decompressor can support, apart from the overall limit in
state capacity.
So the more interesting question is, how many algorithms are likely to be in
actual use at any point in time.
Counting all generations of equipment out there, of course, multiplied by
the number of manufacturers.
It may look nice three weeks from now...

> Type in RTP. So Payload Type 0 means PCM u-law codec, Payload 8 means

It seemed like a good idea at the time, in 1996.
AVT has long since stopped to assign fixed payload types -- there are just
way too many of them for a small field.
(And it's way more expensive to invent a new payload type than a new
decompressor, I might surmise.)

> RFC 2327 negotiates codecs).

Would you trust UE A to upload algorithm X for UE B?

I don't think the dynamic version of this can be made to work without secure
state identifiers.
These need to be at least 6 bytes (probably more; 12 is secure, we are still
investigating whether less can work).
Let's say 8 bytes, times maybe 20 algorithms out there.  Not a big win.
Oh, and you *still* need to upload any user dictionaries.

What you could do for a static solution is to actually tightly manage a
small number space (e.g., 16-bit numbers), by registering algorithms.
Now the problem is that you have to wait for the register updates to
percolate to both UE and fixed network equipment before you can take
advantage of them.

The reason I insist on discussing this seemingly small issue is that I
believe we can eliminate a lot of mechanism by just not doing it.

Or to put it another way, I have the impression we have a psychological
problem ("we can't exchange those bytes all the time, so let's do something
about it") instead of a technical one.  Of course, given that the UDVM
approach is new, this is understandable.  However, we are talking about
probably fewer bytes than the typical HTTP headers for a single web page hit
here.  Once, for registration.

Of course, my analysis may be completely broken.
If I'm right, the only remaining issue for me is whether not having an
ostensible solution for this alleged problem is going to hinder acceptance
of the UDVM.
This is a level 9 decision, not a technical one.

Gruesse, Carsten

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 27 Feb 2002 10:57:30 +0200

Hi Caster:

See my comments inline.

> purpose of which is optimization.

I believe we are speaking about the Capabilities Announcement message in
SigComp. This message, as you said, will carry the range of parameters
that will constrain the algorithm selection at the compressor. What I was
suggesting is that the decompressor already includes a list of algorithms
that, in case one of the them is chosen by the compressor, does not need
to be uploaded to the decompressor.

> of algorithms a decompressor can support, apart from the overall limit in

Agree.

> It may look nice three weeks from now...

Yes, but that does not impact standardization. Whether the decompressor 
contains already the code for 1 or for 1,000 algorithms is not affecting
the performance nor the standard. In a similar example, when my SIP 
terminal publishes support for certain codecs, I may support a big
number of codecs, whereas another terminal not. So what?

> decompressor, I might surmise.)

Certainly static payload types are not assigned nor recommended to use.
However, dynamic payload types are. The point here in the comparison
with SDP was that, there should be a mechanism whereby the decompressor
informs the compressor about already uploaded algorithms. Whether the 
actual mechanism includes static or dynamic payload types, I don't care.
The important thing is to fulfill the requirement to avoid unnecessary
air interface traffic. 

One way to fulfill the requirement is to define a similar mechanism
as in RTP, even with dynamic payload types if you want. 

But in order to progress this, first we need to understand whether the
requirement is reasonable or not. If it is, we can start the discussion
on how to solve the problem.

> Would you trust UE A to upload algorithm X for UE B?

Aren't we doing it now??? Don't we have a UDVM upload whereby an endpoint
uploads the algorithm X to another endpoint?

> Oh, and you *still* need to upload any user dictionaries.

Like I said before. Do we agree on the requirement? If Yes, we can discuss
technical proposals. If Not, we should stop the discussion.

If the requirement is agreed, my suggestion may not be the best one. I don't
have any problem with that. If you think it is not agreeable, let's look 
for other solutions.

> percolate to both UE and fixed network equipment before you can take

Agree.

> believe we can eliminate a lot of mechanism by just not doing it.

So you don't honor the requirement? Then, I doubt SigComp can ever be
used in real life.
 
> This is a level 9 decision, not a technical one.

Well, it is not a level 9 decision. There are several organizations waiting
for the SigComp to be finalized and ready to use it (3GPP being one of them).
We need to understand the requirements and honor them, otherwise we may 
take the risk to deliver something that the customer does not want. That is
not a level 9 decision.

/Miguel

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Wed, 27 Feb 2002 13:25:42 +0100

Miguel,

> the performance nor the standard.

Well, it does, if the idea is that a decompressor announces the algorithms
it has.
Sending 1000 algorithm identifiers is more expensive than sending the
algorithm for most representations of these that I can think of.

> informs the compressor about already uploaded algorithms.

OK, I see.  SDP uses MIME-style identifiers to indicate the codecs that the
application actually wishes to use.

In SDP, this makes sense, as both parties must have implementations of the
codec, or they can't interoperate.
So expending significant effort (often several hundreds of bytes) to find
that lowest common denominator is the right thing to do.

In Sigcomp, the effort to just mandate one algorithm (by simply sending its
decompressor) is in the same ballpark as interchanging the capability
information.
Why bother?  I'd like some numbers, please.

> uploads the algorithm X to another endpoint?

Yes, but in the form of state that will only influence the decompression of
its own packets.

> technical proposals. If Not, we should stop the discussion.

The requirement is to reduce the signaling latency.
I believe we are discussing certain details of the solution right now, which
will influence its performance in one way or the other.
I'm trying to argue that the performance win of a specific approach that
increases complexity is negative or at least not very positive.

(Of course, the approach still remains possible if there is something as
simple as state claims in the protocol, so implementers can go ahead and
make use of these.  I'd still advise them not to bother.)

> So you don't honor the requirement? Then, I doubt SigComp can ever be

Right now, I know of only one technical requirement, the one I cited.
(Well, actually, we have a whole document that essentially details that
technical requirement, draft-ietf-rohc-signaling-req-assump-04.txt; maybe we
have to amend that.)There also is a level 9 requirement to stay clear of
IPR, which I fully support.

Gruesse, Carsten

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 27 Feb 2002 14:38:49 +0200

Hi Carsten:

I changed the subject of the discussion, just to focus in this e-mail on 
requirements.

A group of individuals collected the 3GPP requirements related to SIP and
write them down in an Internet Draft,

http://search.ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-02.txt

Version -03 is on its way and will be submitted before the deadline to MN.

I will encourage to read the actual section 6.5 in that document. There are
several requirements affecting compression.

I will also recommend to read requirements 6.1.1 and 6.1.2. Although these
are general requirements, they are applicable to all the rest of the 
requirements and possible solutions.

/Miguel

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Wed, 27 Feb 2002 14:46:48 +0100

Miguel,

does this list of requirements take into account the UDVM approach?
It does seem to predate its adoption.

Gruesse, Carsten

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 27 Feb 2002 15:53:12 +0200

Hi:

No, these requirements were discussed prior to the UDVM approach.

As I said, a new version of this draft will be shortly submitted.
I need to discuss with the rest of the co-authors some better wording
that reflects the latest assumptions in Rohc and 3GPP.

I will announce the draft in this mailing list as well.

/Miguel