Subject: RE: [rohc] SigComp, the SIP dictionary and local states

From: "Lepine, Jean-Pierre" <[email-masked]>
Date: Fri, 4 Mar 2005 09:16:42 -0500

Pekka,

I'm not sure I get the point of your last paragraph...so I will reformulate
a bit my thoughts.
What I meant about the referred sentence in the introduction of RFC 3485 is
simply that "...in the FIRST message sent by a compressor..." leaves a door
open that this may not be true for every subsequent messages sent by the
same compressor. Following our discussion, I think it should rather say
"...in EVERY message sent by a compressor...".

At this point, I am satisfied about my original concerns. However, it would
be nice if you could clarify your last paragraph because I feel I am missing
something there...

In your example, I understand that only 2 endpoints are involved with
compressor 1 and compressor 2 being at the same endpoint, hence
communicating with the same remote endpoint. Furthermore, when compressor 2
sends message m2, the dialog involving compressor 1 has ended but the
lifetime of the states created during this dialog has been extended over the
session boundary as per section 5.3 of RFC 3321. If this is all correct, I
am not aware of any specification on how an implementation can achieve this,
in particular for SIP. Such a specification would be needed for
interoperability and section 3 of draft-ietf-rohc-sigcomp-sip-01.txt is
indeed talking about this idea.
Besides, what's the point of compressor 1 setting the I-bit ?

--Jean-Pierre

-----Message d'origine-----
De : Pekka Pessi [mailto:[email-masked]]
Envoyé : 4 mars, 2005 05:17
À : Lepine, Jean-Pierre
Cc : Pekka Pessi; [email-masked]
Objet : Re: [rohc] SigComp, the SIP dictionary and local states

"Lepine, Jean-Pierre" <[email-masked]> writes:
>From your answer, I understand that for a SIP implementation, any
compressor can safely assume
>that the SIP dictionary is ALWAYS accessible, no matter what happens. In
other words, there is
>absolutely no way that this local state can become inaccessible to any
compressor, even if a
>compressor sets the I-bit, because this local state is mandatory.

>Correct ?

That is right.

>If this is indeed correct, maybe the relevant RFCs and/or
>internet-drafts for a SIP implementation could be clearer about
>this fact, unless I missed the cue... 

I must agree with you, more clarity is always needed. Now expired
draft draft-ietf-rohc-sigcomp-sip-01.txt mentioned RFC 3485 LAS,
too, perhaps the resurrected draft could make this unambiguous.

>For example, recall the
>last sentence in the introduction of RFC 3485:

>"The static SIP/SDP dictionary constitutes a SigComp state that
>can be referenced in the first SIP message that the compressor
>sends out."

>To me, this specifies a certainty for the first message but not
>necessarily for every message.

How the UDVM can know if this is not the first message? Let's say
we have the compressor 1 that sets the I bit. Another compressor
instance, compressor 2, from the same endpoint sends a message m2. 
The decompression of the message m2 uses the RFC 3585 dictionary
and the state items provided by compressor 1 in compartment #1. 
(On a closer look, this has not been mentioned in RFC 3321, but
this is fairly obvious from section 5.3 in any case.) Only after
seeing the message m2, application can decide that it belongs to a
new compartment, compartment #2.

--Pekka

>-----Message d'origine-----
>De : Pekka Pessi [mailto:[email-masked]]
>Envoyé : 3 mars, 2005 08:16
>À : Lepine, Jean-Pierre
>Cc : [email-masked]
>Objet : Re: [rohc] SigComp, the SIP dictionary and local states

>"Lepine, Jean-Pierre" <[email-masked]> writes:
>>I would like to clarify a few things about SigComp, the SIP dictionary and
local states.:p>

>>The SIP dictionary is a mandatory local state for a SIP implementation of
SigComp. In RFC
>3485,
>>the introduction says::p>

>>"The static SIP/SDP dictionary constitutes a SigComp state that can be
referenced in the first
>>SIP message that the compressor sends out.":p>

>>Also, regarding the requested feedback data, RFC 3320 at p.54 says::p>

>>"...the compressor sets the I-bit to 1 if it does not wish (or no
>>longer wishes) to access any of the locally available state items
>>offered by the receiving endpoint.":p>

>>From this, I understand that a compressor can ALWAYS access the
>>SIP dictionary at the remote endpoint, UNLESS it sets the I-bit
>>in its requested feedback data. This is the only way that the SIP
>>dictionary can become inaccessible to a compressor.:p>

>Generally speaking, a UDVM instance can access state items from
>other compartments as well as from their own. This has been
>mentioned in RFC 3321. It makes sense, because usually the SigComp
>implementation can not know to which compartment the message
>belongs. It is up to application to decide.

>So, even setting the I-bit does not make the SIP/SDP state
>unavailable.

>...
>>I have a concern if an implementation chooses to create local
>>states on a per-compartment basis, which would be legal according
>>to the above statement. In this case, I understand that if a
>>remote compressor creates new state items, these can require
>>lower priority states, including local states, to be freed and
>>hence become inaccessible to this compressor. If I am right, this
>>would be another way that the SIP dictionary can become
>>inaccessible to a compressor. However, I hope I am wrong because
>>this could likely create interoperability issues, since a
>>compressor has no way to know how local states are handled at the
>>remote endpoint, i.e. created on a per-compartment basis or
>>not.:p>

>RFC 3320 makes it quite clear if I-bit is set, an endpoint can
>delete state items which it has offered to remote compressor.
>However, It does not tell whether the state items can be deleted
>when the I-bit is not set.

>This was discussed last August and November. However, the
>conclusion was a bit confusing, if there was a conclusion.

>I think that the consensus was that the compartment-specific
>locally-available state items (LASI for short - that is very
>fragile stuff in Finnish) can be deleted even without UDVM
>bytecode setting the I-bit if the UDVM saves state items that push
>the LASI out of the compartment. The controversial issue was
>whether the local compressor can add more LASIs that can sneakily
>push *earlier* LASIs out from compartment when the UDVM creates
>its own state items. This may lead to failed decompression of
>messages sent by remote end, because the knowledge of later LASI
>may not reach remote at all or only after it has sent its own
>message.

>*I* think that both choises pretty much makes those states
>useless, unless the compressor can make sure the compartment state
>has not been changed since the remote end sent the message
>offering the LASIs. IOW, if remote end has since received or sent
>other messages which has modified the state items in compartment,
>the LASI may be lost. This can be quite tricky, as the UDP packets
>can be lost, duplicated or delivered out of order.

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

---

From: Pekka Pessi <[email-masked]>
Date: Fri, 04 Mar 2005 16:52:13 +0200

"Lepine, Jean-Pierre" <[email-masked]> writes:
>I'm not sure I get the point of your last paragraph...so I will reformulate a bit my thoughts.
>What I meant about the referred sentence in the introduction of RFC 3485 is simply that "...in
>the FIRST message sent by a compressor..." leaves a door open that this may not be true for
>every subsequent messages sent by the same compressor. Following our discussion, I think it
>should rather say "...in EVERY message sent by a compressor...".

>At this point, I am satisfied about my original concerns. However, it would be nice if you
>could clarify your last paragraph because I feel I am missing something there...

I'm sorry, the reference to section 5.3 probably just made example
more uncomprehensive.

>In your example, I understand that only 2 endpoints are involved with compressor 1 and
>compressor 2 being at the same endpoint, hence communicating with the same remote endpoint. 
>Furthermore, when compressor 2 sends message m2, the dialog involving compressor 1 has ended
>but the lifetime of the states created during this dialog has been extended over the session
>boundary as per section 5.3 of RFC 3321. If this is all correct, I am not aware of any
>specification on how an implementation can achieve this, in particular for SIP. Such a
>specification would be needed for interoperability and section 3 of
>draft-ietf-rohc-sigcomp-sip-01.txt is indeed talking about this idea.

My intention was to say that the session involving compressor 1
has *not* ended when compressor 2 starts new session...

>Besides, what's the point of compressor 1 setting the I-bit ?

If compressor 1 does not want to use shared compression, nor it
understand any LAS, then it would make sense to ask that remote
end stop wasting bw and udvm memory for announcements...

--Pekka

>>From your answer, I understand that for a SIP implementation, any compressor can safely assume
>>that the SIP dictionary is ALWAYS accessible, no matter what happens. In other words, there is
>>absolutely no way that this local state can become inaccessible to any compressor, even if a

>>>I would like to clarify a few things about SigComp, the SIP dictionary and local states.:p>

>>>The SIP dictionary is a mandatory local state for a SIP implementation of SigComp. In RFC
>>3485,

>>>"The static SIP/SDP dictionary constitutes a SigComp state that can be referenced in the
>first