Subject: [rohc] SigComp dynamic compression and Sip

From: Herve Siegrist <[email-masked]>
Date: Wed, 01 Jun 2005 11:36:14 +0200

Hi folks,

I am having quite a few issues with dynamic compression as described in 
RFC3321 (well, I also have a lot of issues with shared compression, but 
that's for later...). In theory, all goes well: each endpoint compresses 
new messages according to the previous ones, the remote decompressor 
creates a new state holding the bytecode along with the current set of 
decompressed messages, and, when compressing the next message, sends the 
created state id back to the originator to tell it the state item was 
properly created. This allows the initiator to keep using the saved data 
for the next compression.

However, from a practical standpoint, I have some issues regarding how 
this can work for real traffic which is not symmetrical. For example, 
with SIP, the sequence typically consists of:
    - INVITE from proxy to server,
    - Trying from proxy to client,
    - Ringing from proxy to client,
    - Ok from proxy to client,
    - ACK from client to proxy.

In this case, I am not clear at all on the mechanism to use on the proxy 
side to handle dynamic compression when sending the Trying, Ringing, and 
Ok sequence. Obviously, this is where dynamic compression would prove 
the most useful, these three message being almost identical in most 
regards. However, as there is not message send by the client in the mean 
time, my proxy compressor does not have any way to know that the proper 
states have really been created on the client side.

Hence, how can the compressor compression the Ringing message, for 
example, can use dynamic compression while it does not know if the 
proper state information associated with the earlier decompression of 
the Trying message has been successful?

How is this type of figure supposed to be handled? Do we have to give-up 
on dynamic decompression in this case, even though this is a typical 
sequence where it would prove most useful? Could we assume, even though 
this is not quite what the RFC indicates, that the states were properly 
created on the client side and use dynamic compression anyway (and retry 
with static compression if we end-up having to retransmit all that due 
to a lack of response from the client, assuming a compression failure 
occured?)?

I am really not very clear on this issue, and any ideas or 
clarifications would be quite welcome there...

The same kind of issues applies when the client or the proxy needs to 
retransmit a previous message, either because the previous message was 
lost or because the remote endpoint did not respond in time. In this 
case, still assuming the remote does not send us anything back, there is 
no way to know the state of the remote (no state was created if the 
message was lost, a state was created if the reply is delayed), which in 
my opinion means that it becomes necessary to detect retransmissions at 
the SigComp level and restart everything from scratch whenever this 
occurs, i.e.: send back the original bytecode to make sure the remote is 
in a known state.

Any comment on this one either?

Herve Siegrist.

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

---

From: "Gustav E" <[email-masked]>
Date: Wed, 01 Jun 2005 16:03:33 +0200

Hi Herve,

Regarding dynamic compression it is my understanding that a compressor must 
not use a remote state if the compressor can not be sure that it has been 
established correctly.
The way to go here is naturally to use some sort of acknowledgement, i.e. to 
make sure some feedback item is returned from the remote end to indicate 
that the state has been created. (The data is an implementation choise, it 
can be a partial state id for instance)
As you described there are some things to consider, for instance the fact 
that a lot of protocols, such as SIP, is not always symmetric. In this case 
I guess that a safe way to go can be to have logic in the compressor 
according to the following:
1. Send a compressed message establishing a new dyn state.
2. Do not use the new state until it has been acked.
3. If the compressor has compressed more the X number of messages without 
having recieved an ack on the sent message, the compressor should view the 
dyn state establishment as unsucessfull and not use it. (Where X is to be 
choosen based on protocol knowledge). If so, to be safe the compressor 
should issue a remote state remove prior to trying to establish a new dyn 
state.
4. To simplify the logic of the compressor it is probably a good idea to 
keep only one dynamic state at a time.

Ofcourse this creates a compression with a bit less ratio then the ideal one 
where each message sent is based on the previous one. In the SIP case I 
guess that since a lot of data is still the same, eventhough a few messages 
are "lost" the ratio does not suffer all that much.

As far as I know, if you stick to some type of mechanism as described above, 
retransmissions and other real-life situations should not be a problem. Do 
you agree?

This is just one example of how I guess the problem can be solved, hope it 
will give you some hints.

/Gustav

>From: Herve Siegrist <[email-masked]>
>To: [email-masked]
>Subject: [rohc] SigComp dynamic compression and Sip
>Date: Wed, 01 Jun 2005 11:36:14 +0200
>
>Hi folks,
>
>However, from a practical standpoint, I have some issues regarding how this 
>can work for real traffic which is not symmetrical. For example, with SIP, 
>the sequence typically consists of:
>side to handle dynamic compression when sending the Trying, Ringing, and Ok 
>sequence. Obviously, this is where dynamic compression would prove the most 
>useful, these three message being almost identical in most regards. 
>However, as there is not message send by the client in the mean time, my 
>proxy compressor does not have any way to know that the proper states have 
>really been created on the client side.
>
>Hence, how can the compressor compression the Ringing message, for example, 
>can use dynamic compression while it does not know if the proper state 
>information associated with the earlier decompression of the Trying message 
>has been successful?
>
>How is this type of figure supposed to be handled? Do we have to give-up on 
>dynamic decompression in this case, even though this is a typical sequence 
>where it would prove most useful? Could we assume, even though this is not 
>quite what the RFC indicates, that the states were properly created on the 
>client side and use dynamic compression anyway (and retry with static 
>compression if we end-up having to retransmit all that due to a lack of 
>response from the client, assuming a compression failure occured?)?
>
>I am really not very clear on this issue, and any ideas or clarifications 
>would be quite welcome there...
>
>retransmit a previous message, either because the previous message was lost 
>or because the remote endpoint did not respond in time. In this case, still 
>assuming the remote does not send us anything back, there is no way to know 
>the state of the remote (no state was created if the message was lost, a 
>state was created if the reply is delayed), which in my opinion means that 
>it becomes necessary to detect retransmissions at the SigComp level and 
>restart everything from scratch whenever this occurs, i.e.: send back the 
>original bytecode to make sure the remote is in a known state.
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

---

From: Adam Roach <[email-masked]>
Date: Wed, 01 Jun 2005 09:15:42 -0500

Gustav E wrote:

>
> Ofcourse this creates a compression with a bit less ratio then the 
> ideal one where each message sent is based on the previous one.

If you're using a negative acknowledgment scheme, you *can* get such a 
ratio. See RFC 4077.

/a

---

From: Herve Siegrist <[email-masked]>
Date: Wed, 01 Jun 2005 16:32:50 +0200

Did not see this RFC so far, thanks for pointing it out...

Seems to me it solves my problem: send everything and assume it will 
work on the remote side, unless I get a NACK back in which case I toggle 
my dynamic compression flag and wait for an application retransmission 
(unless the nack reports a more serious problem of course).

Thanks,
Herve.