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

From: "Lepine, Jean-Pierre" <[email-masked]>
Date: Thu, 3 Mar 2005 09:29:15 -0500

Pekka,

I appreciate your help but I'd like to turn the question around in order to
close this discussion.

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

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

BR,
--Jean-Pierre

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

---

From: Pekka Pessi <[email-masked]>
Date: Fri, 04 Mar 2005 12:17:22 +0200

"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

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