Subject: RE: [rohc] SigComp Implementer's guide - it's that time again

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 1 Mar 2006 14:28:51 -0000

Hi Cristian,

> cristian: so, you are sugesting here that the sigcomp stack should
> realize a 200OK is _retransmitted_ by the sip stack; so your sigcomp
> stack has to be able to (re)parse a sip message and interpret its
> meaning or equivalently you'll have to signal somehow: 
> careful now here
> it comes a 200OK, right? would that not be overkill for 
> sigcomp and actually for
> your whole implementation?

Whether the SigComp stack knows that a particular message is one that is
being retransmitted one or not is up to the implementer of the SIP and
SigComp stacks and the interface between the two.

This is an example to point out that there may be cases when it would be
beneficial for the general behaviour of SigComp to be to send feedback
multiple times.

This would require, as John says, clarification that although 3320
section 5 says there is 'no need to send a given piece of feedback more
than once', that actually the implementation *should* transmit feedback
repeatedly (on any message being sent before the next feedback request
is received).

[This does not put any requirement on the interface between SIP and
SigComp.]

Best regards,

Abbie
> 
> > 
> > The statements you quoted below state only that the 
> feedback SHOULD be
> > returned.  The note itself does not contain any 'standards 
> language'.
> > Is there actually a case for clarifying this in the 
> implementer's guide
> > that feedback should be returned multiple times?
> > 
> > (In either case an implementation has to deal with a remote
> > implementation that doesn't do so, but it's a question of what the
> > expected behaviour should be.)
> > 
> > What do you think?
> > 
> > Best regards,
> > 
> > Abbie
> > > 
> > > I said:
> > > 
> > > > So the 
> > > > scenarios covered by your new section 9.2 simply do not 
> > > > apply, if you stick to the SIGCOMP RFC. 
> > > 
> > > Perhaps I should have said that the scenarios only apply 
> with reduced
> > > scope - to the case when an incoming message with requested 
> > > feedback is
> > > followed by another incoming message with 
> > > requested_feedback_location ==
> > > 0 or Q == 0, without an outgoing message have been sent 
> in between.
> > > 
> > > John
> > > 
> > > > -----Original Message-----
> > > > From: John Barber [mailto:[email-masked]] 
> > > > Sent: 28 February 2006 14:35
> > > > To: Surtees, Abigail; [email-masked]
> > > > Subject: RE: [rohc] SigComp Implementer's guide - it's that 
> > > time again
> > > > 
> > > > Hi Abbie,
> > > > 
> > > > Sorry for the lateness of this reply.
> > > > 
> > > > Re: Updating feedback requests:
> > > > 
> > > > In your previous email, you wrote: "I assume that when an 
> > > > endpoint receives a valid message, it updates the feedback 
> > > > data for that compartment.  The endpoint should then set this 
> > > > feedback on every message sent within the compartment until 
> > > > it receives another valid message that updates the feedback."
> > > > 
> > > > This is also the assumption behind the wording of your 
> > > > proposed new section 9.2 below. However, this is contrary to 
> > > > what is specified in SIGCOMP Section 5:
> > > > 
> > > > *************
> > > >     Additionally, if the state handler passes some requested 
> > > > feedback to
> > > >     the compressor, then it SHOULD be returned in the 
> next SigComp
> > > >     message generated by the compressor (unless the state 
> > > > handler passes
> > > >     some newer requested feedback before the older 
> feedback has been
> > > >     sent, in which case the older feedback is deleted). 
> > > >     If present, the requested feedback item SHOULD be copied 
> > > > unmodified
> > > >     into the returned_feedback_item field provided in 
> the SigComp
> > > >     message.  Note that there is no need to transmit 
> any requested
> > > >     feedback item more than once.
> > > > *************
> > > > 
> > > > This is saying that any requested feedback should be sent on 
> > > > the *next* message generated by the compressor *only*. So the 
> > > > scenarios covered by your new section 9.2 simply do not 
> > > > apply, if you stick to the SIGCOMP RFC.
> > > > 
> > > > So, my question is, is it the case that the SIGCOMP spec is 
> > > > not viable in this respect and needs to be corrected, or has 
> > > > one of us made a mistake? If you are intentionally 
> > > > contradicting the SIGCOMP spec then I think this needs to be 
> > > > made clearer, e.g. by an explicit reference to SIGCOMP 
> > > > Section 5 and a statement that these provisions of SIGCOMP 
> > > > are to be disregarded.
> > > > 
> > > > Best regards, John
> > > > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> 
> -- 
>  _          | There are many people who use UNIX or Linux  
> (_'_        | who IMHO do not understand UNIX.
>   (_'rist   |              --David Korn  
> GPG public key at wwwkeys.de.pgp.net
> 

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 2 Mar 2006 10:36:58 -0000

Hi John, all,

On looking into this further, section 6.2 seems to confuse things,
depending on what you read into it.  However, I think RFC3320 is pretty
clear.  Let's see if I can summarise this and generate a list of
questions to be answered.

>From the RFC3320 perspective *only*:

RFC3320 discusses 'locally available state' (LAS):  all the discussion
about advertisements refers to  LAS.  There is no mention of advertising
anything other than LAS.  LAS is a potentially confusing term, but (I
think) well defined -- it is state that is available at a given endpoint
(rather than just a compartment).

According to Section 3.3.3. examples of LAS are dictionaries and
bytecode.  Nothing is said about their lifetime.  However, for them to
be 'locally available' they must exist within the endpoint, so why would
they ever be deleted?

As you point out, Section 6.2 allows for the possibility of LAS items to
be mapped to a compartment.  However, I think that the point 6.2 is
making is: *if you do this*, then you must use retention priority 65535
to avoid interference with state requests.  I do not think it is
suggesting that this is what you *should* do.  (The only reason I can
think of for so doing is to control which local state is advertised to a
given endpoint and for how long.)

Question: If you *do* map LAS items to a compartment, what happens if
the item is larger than the SMS for the compartment?  e.g. SIP/SDP
static dictionary (3.5kbyte) with 2kbyte compartment?  Does this imply
that the dictionary is truncated to fit the compartment?!

So when an endpoint receives an advertisement it knows:

- that a piece of state with that identifier is available at the peer
endpoint;
- that if the state is mapped to a compartment, this will not interfere
with state-creation requests;
- that if it recognises the advertised state ID, it can make use of the
state; and
- that unless it knows otherwise, the state will persist outside of the
compartment.

Adding the discussion in RFC3321:

RFC3321 brings in the concept of advertising shared_state_ids (5.2) and
acked_state_ids (5.1).

Shared_states are well defined - they are stored within a compartment;
created at priority 65535; and if the receiving endpoint doesn't use
shared-mode, then their advertisement doesn't affect interoperability.

An acked_states_id seems to identify a piece of state that the remote
endpoint has requested to be created.  Performing such an advertisement
seems to imply that either:
- the use of the advertisement has been updated by an informational
draft; or
- in advertising it, the endpoint has turned the piece of state into LAS
(either within the compartment or not).

The receiver of such an ack needs to infer whether or not the state is
mapped to a compartment and what its lifetime is.  However, if it *is*
viewed as LAS, then we note that LAS *must* have priority 65535.

Question: what does a vanilla RFC3320 implementation assume on receipt
of such an advertisement?
i)   that the ID of a requested state-create collides with LAS (so
should not be accessed)?
ii)  that the requested state-create matched an already existing piece
of LAS (surely only for well-known state items, e.g. bytecode?!);
iii) assume that the other endpoint has turned this state into LAS (at
priority -1);
iv)  ignore it, because it doesn't match any LAS known by this endpoint.

(iv) makes the most sense, I think, although (i) seems more
conservative. (iii) makes no sense -- there is no indication within
RFC3320 that this could happen.  (ii) may also be reasonable, in certain
cases.

In summary:

* An endpoint advertising non shared-mode local state may map it to, and
subsequently delete it from, a compartment but should not delete it
altogether;

* What should happen when mapping LAS to a compartment where the LAS
item(s) is/are larger than the compartment SMS?

* What should an 'RFC3320 only' implementation assume about the
advertisement of the state id of state it requested to be created?

* What *are* the allowed semantics of state advertisements; where should
they be defined; and can they cause incompatibilities with base RFC3320
(see previous question)?

And in answer to your question about why the authors allowed it; I can
only assume that it is because the mechanism is needed for shared mode
and both RFCs were written at the same time.  The authors are, of
course, welcome to clarify this. :-)

Best regards,

Abbie 

> Sent: Tuesday, February 28, 2006 3:39 PM
> Subject: RE: [rohc] SigComp Implementer's guide - it's that time again
> 
> Hi again,
> 
> Sorry again for late feedback. This time about "10.3  Semantics of
> advertisements of local state items"
> 
> I like your interpretation of RFC3320 on this one. My initial 
> reading of
> the spec was that an implementation could choose to implement
> locally-available state items as being mapped to 
> compartments, and that
> this could lead to the locally-available state item being "pushed out
> of" the compartment and suddenly becoming unavailable. In the SIP
> context, this could mean that the SIP/SDP static dictionary would
> suddenly become unavailable - not nice!
> 
> However, this interpretation was based not on reading RFC3321 
> 5.1.2 but
> on SIGCOMP itself, RFC3320 6.2:
> 
> ************************************
> If the state creation request exceeds the state memory allocated
>       to the compartment, sufficient items of state created 
> by the same
>       compartment are freed until enough memory is available to
>       accommodate the new state.
> ...
> Note that locally available state items (as described in Section
>    3.3.3) need not be mapped to any particular compartment.  
> However, if
>    they are created on a per-compartment basis, then they must not
>    interfere with the state created at the request of the remote
>    endpoint.  The special state_retention_priority of 65535 
> is reserved
>    for locally available state items to ensure that this is the case.
> ...
> The state_retention_priority of 65535 is
>       reserved for locally available states; these states 
> must always be
>       freed first.
> ...
> When a state item is freed, it is
>       removed from the list of states created by the 
> compartment and the
>       memory cost of the state item no longer counts towards the total
>       cost for the compartment.  Note, however, that identical state
>       items may be created by several different compartments, 
> so a state
>       item must not be physically deleted unless the state handler
>       determines that it is no longer required by any compartment.
> ************************************
> 
> The above could be taken to mean that an item of 
> locally-available state
> freed from a compartment should be physically deleted - after all, it
> may be "no longer required by any compartment". That is how I 
> initially
> understood it.
> 
> So I guess what I would like to see is a specific reference to SIGCOMP
> 6.2 in your new Implementer's Guide 10.3, clarifying the 
> point that when
> a locally-available state item is freed from a compartment, the state
> item itself should not be deleted.
> 
> Also the following proposed wording is not in accordance with the
> language of RFC3320:
> 
> >    The
> >    implication of this is that these state items are not 
> > within the SMS
> >    of any compartment and that, once they have been 
> > advertised within a
> >    compartment to a remote compressor, they will be available 
> > for use by
> >    that compressor at least until the end of the 
> compartment lifetime.
> 
> What SIGCOMP actually seems to be saying is that locally 
> available state
> items *may* be within the SMS of a compartment, but the priority rules
> ensure that they are first to drop out of the compartment, so 
> as not to
> conflict with other state items in the compartment. Though I 
> have to say
> I don't really understand the intention of this design. What is the
> possible advantage of mapping a locally-available state item to a
> compartment, and why did the SIGCOMP authors allow it?
> 
> Regards, John
>  
> 
> > From: Surtees, Abigail [mailto:[email-masked]] 
> > Sent: 28 February 2006 11:14
> > To: [email-masked]
> > Hi All,
> > I haven't received any feedback (other than Cristian's 
> > question) on these issues and the deadline for drafts is fast 
> > approaching.
> > 
> > Therefore, please find inline my proposed text for each 
> > issue.  If I don't receive any feedback by 3pm Thurs GMT then 
> > I'll assume it's ok and submit the draft accordingly.
> > 
> > Best regards,
> > 
> > Abbie
> > 
> > > 
> > > Feedback:
> > > 
> > 
> > "9.2  Updating feedback requests
> > 
> >    When an endpoint receives a valid message it updates the 
> requested
> >    feedback data for that compartment.  The endpoint should then set
> >    this feedback in every message sent within that 
> > compartment until it
> >    receives another valid message that updates the feedback.
> > 
> >    Section 9.4.9 of SigComp [1] states that when
> >    requested_feedback_location equals zero, no feedback 
> > request is made.
> >    However, there is no indication of whether this means that the
> >    existing feedback data is left untouched or this means that the
> >    existing feedback data should be overwritten to be 'no feedback
> >    data'.  If requested_feedback_location equals zero, the existing
> >    feedback data should be left untouched and returned in any 
> > subsequent
> >    messages as before.
> > 
> >    Section 9.4.9 of SigComp [1] also makes no statement about what
> >    happens to existing feedback data when 
> requested_feedback_location
> >    does not equal zero but the Q flag indicating the 
> > presence/absence of
> >    a requested_feedback_item is zero.  In this case, the existing
> >    feedback data should be overwritten to be 'no feedback data'."
> > > 
> > > Packet re-ordering:
> > > 
> > 
> > "Message re-ordering
> > 
> >    SigComp [1] makes only one reference to the possibility of 
> > misordered
> >    messages.  However, the statement that the 'compressor 
> MUST ensure
> >    that the message can be decompressed using the resources 
> > available at
> >    the remote endpoint' puts the onus on the compressor to 
> > take account
> >    of the possibility of misordering occurring.
> > 
> >    Whether misordering can occur and whether that would 
> have an impact
> >    depends on the compartment definition and the transport 
> protocol in
> >    use.  Therefore, it is up to the implementer of the compressor to
> >    take these factors into account."
> > > 
> > > State advertisements:
> > > 
> > > I think section 5.1.2 of 3321 confuses the statements in
> > > 3.3.3 and could
> > > do with clarification. 
> > 
> > 10.3  Semantics of advertisements of local state items
> > 
> >    In Section 3.3.3 of SigComp [1] the examples of locally available
> >    state items are pieces of state that an endpoint has 
> available but
> >    that the remote compressor has not requested to be created.  The
> >    implication of this is that these state items are not 
> > within the SMS
> >    of any compartment and that, once they have been 
> > advertised within a
> >    compartment to a remote compressor, they will be available 
> > for use by
> >    that compressor at least until the end of the 
> compartment lifetime.
> > 
> >    SigComp Extended [2] discusses their use in two other ways: local
> >    endpoint initiated acks and shared mode (which with the 
> > clarification
> >    of creation of state with minimum retention priority provided in
> >    Section 5.3) clearly specifies use of the advertisement of state.
> > 
> >    The implication of local endpoint initiated acks (section 5.1.2),
> >    however, is that the advertisement is of a piece of state that is
> >    within the SMS and can, therefore, be pushed out of the 
> compartment
> >    in the ordinary running of the state handler.  This seems to
> >    contradict section 3.3.3 of SigComp.
> > 
> >    [Editor's note: The above provides the statement of an area that
> >    could cause confusion.  If 5.1.2 is to be used, the 
> > semantics of the
> >    state advertisement need further clarification.  It is not 
> > yet clear
> >    what these semantics will be.  (See also ongoing discussion about
> >    compartment definition).]
> > 
> > 
> > > 
> > > 
> > > > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf 
> > > > Of Surtees, Abigail
> > > > Sent: Thursday, February 02, 2006 11:54 AM
> > > > To: [email-masked]
> > > > Subject: [rohc] Implementer's guide - it's that time again
> > > > 
> > > > Hi All,
> > > > 
> > > > The implementer's guide expired in January so it's time 
> > to update it 
> > > > again.  There's one comment outstanding about clarifying 
> > section 3.2 
> > > > MULTILOAD 
> > > > 
> > (http://www1.ietf.org/mail-archive/web/rohc/current/msg03949.html).
> > > > 
> > > > Are there any other issues that should be clarified in the 
> > > > implementer's guide?  If so, please raise them on the 
> > list by Friday 
> > > > Feb 10th.
> > > > 
> > > > Best regards,
> > > > 
> > > > Abbie
> > > > 
> > > > Abbie Surtees
> > > > Senior Engineer
> > > > Roke Manor Research Ltd
> > > > Old Salisbury Lane
> > > > Romsey, SO51 0ZN
> > > > Tel:   +44 (0) 1794 833131
> > > > 
> > > >

---

From: "John Barber" <[email-masked]>
Date: Thu, 2 Mar 2006 17:25:49 -0000

Hi again,

Sorry, forgot to include rohc list as an adressee.

Also, on reflection, I think there is a difference between the scenarios
of Impl Guide 5.3 Examples 1/2 and scenarios involving message loss with
ordinary state items.

If compressor A sends 2 messages to endpoint B which both save state,
and which won't both fit into the SMS at B, and if the second of them is
not acknowledged (could be lost message 2 from A to B or lost Ack 2 from
B to A) then compressor A doesn't know which of the two state items will
be present at B, but at least it is aware that there is likely to be a
problem, and could avoid trouble by not assuming the presence of either
state item.

Whereas in the scenarios of Impl Guide section 5.3, Endpoint B doesn't
even have the faintest inkling that anything might be going wrong before
the decompression failure at A occurs. I think the key to this
difference is that in this scenario the saving of state is initiated by
the compressor without the knowledge of the remote endpoint. Normal
pattern is that state is saved by the decompressor but acting under the
control of the remote compressor. This factor seems to me to be more
relevant to these examples than the state retention priority being -1.

Regards, John

> From: John Barber 
> Sent: 02 March 2006 16:18
> To: 'Surtees, Abigail'
> I'm going to raise another comment. Again, sorry about the 
> lateness - I have just been re-reading the various documents 
> to get a better overall picture of the state handler in order 
> to respond on the previous issue, when I came across this. 
> Please feel free to ignore this until the next review cycle 
> if that is convenient.
> 
> Anyway, I'm puzzled by the Implementer's Guide Section 5.3.
> 
> Firstly, I don't understand the notations used in the Example 
> 1 diagram. What do "SM1", "BC", "BF1" etc mean? This is hard 
> to understand because (a) it uses different notation from 
> RFC3321 Figure 2 (to which it closely relates) and (b) it 
> does not include a legend or annotations to explain what it 
> means. I think Example 1 should use the same symbols as 
> RFC3321 Figure 2 and should include a legend.
> 
> Secondly, the section talks about problems specific to use of 
> retention priority -1 state items, but the examples given 
> both involve loss of messages. As far as I can see, message 
> loss could cause misunderstandings and possible decompression 
> failures when dealing with state items of any priority, not 
> just -1 priority items. If there anything specific about 
> priority -1 which could cause extra problems with these 
> items, then the text needs to make it clear what this is.
> 
> Best regards, John
> 
> issue.  If I 
> > don't receive any feedback by 3pm Thurs GMT then I'll 
> assume it's ok 
> > and submit the draft accordingly.
> > 
> > Best regards,
> > 
> > Abbie
> > 
> > > 
> > > Feedback:
> > > 
> > 
> compartment until 
> > it
> >    requested_feedback_location equals zero, no feedback request is 
> > made.
> presence/absence 
> > of
> available 
> > at
> >    the remote endpoint' puts the onus on the compressor to take 
> > account
> >    implication of this is that these state items are not within the 
> > SMS
> advertised within 
> > a
> >    compartment to a remote compressor, they will be 
> available for use 
> > by
> >    could cause confusion.  If 5.1.2 is to be used, the semantics of 
> > the
> >    state advertisement need further clarification.  It is not yet 
> > clear

---

From: "John Barber" <[email-masked]>
Date: Thu, 2 Mar 2006 22:29:33 -0000

Hi Abbie, all,

> However, I think 
> RFC3320 is pretty clear.

Hmmm, I was just thinking that RFC3320 is pretty confusing!

> According to Section 3.3.3. examples of LAS are dictionaries 
> and bytecode.  Nothing is said about their lifetime.  
> However, for them to be 'locally available' they must exist 
> within the endpoint, so why would they ever be deleted?

I agree that they should never be deleted. Yet there are passages in
RFC3320 (as quoted by me below)which seem to suggest that they should.
Even the Implementation Guide, section 8, seems to suggest this: "The
endpoint receiving an I-bit of 1 can reclaim the memory used to store
the locally available state items." Surely, this must mean that they
will be deleted? 

> Question: If you *do* map LAS items to a compartment, what 
> happens if the item is larger than the SMS for the 
> compartment?  e.g. SIP/SDP static dictionary (3.5kbyte) with 
> 2kbyte compartment?  Does this imply that the dictionary is 
> truncated to fit the compartment?!

Good question. Truncating the item to fit the compartment is not viable.
Remember that the state_id for the state item will be recalculated if
the state item is truncated. Therefore the remote compressor would not
be able to send bytecode to access the state item using the well-known
state_id.

Which prompts the question: IF, at state creation time, LAS doesn't obey
the normal compartment rules for state items, and, during its lifetime,
it does not effectively occupy space in the compartment (because it has
priority -1 so will not impinge on other state items), and, when it is
removed from the compartment, does not behave like other state items
associated with a compartment, in that it will never be physically
deleted, THEN, in what sense can LAS really be said to be mapped to the
compartment? I would suggest that the whole concept of mapping LAS to a
compartment serves only to generate confusion, but I agree with your
approach which is to clarify the possible harmful interpretations as
being the wrong ones.

> An acked_states_id seems to identify a piece of state that 
> the remote endpoint has requested to be created.  Performing 
> such an advertisement seems to imply that either:
> - the use of the advertisement has been updated by an 
> informational draft; or
> - in advertising it, the endpoint has turned the piece of 
> state into LAS (either within the compartment or not).

RFC 3321 Section 5.1.2 describes the acked_state_ids generated by an
endpoint automatically to acknowledge state items created at that
endpoint via returned parameters, removing the need for acknowledgment
to be done through the END-MESSAGE/requested feedback/returned feedback
path. There is no suggestion that sending such an automatic
acknowledgment changes the priority of the state item or converts it
into an LAS item - to do that would surely be unacceptable behaviour -
consider that the remote might be vanilla RFC3320 and could not be
expecting such a behaviour. So, I'm sure the intention of RFC3321 *is*
to specify a new use of the SIGCOMP parameters advertisement mechanism
(is there a rule that says informational RFCs are not supposed to do
that?)

> Question: what does a vanilla RFC3320 implementation assume 
> on receipt of such an advertisement?
> ii)  that the requested state-create matched an already 
> existing piece of LAS (surely only for well-known state 
> items, e.g. bytecode?!);
> iii) assume that the other endpoint has turned this state 
> into LAS (at priority -1);
> conservative. (iii) makes no sense -- there is no indication 
> within RFC3320 that this could happen.  (ii) may also be 
> reasonable, in certain cases.

I would agree that (iv) makes most sense. I would expect an
implementation to inspect the state_ids in the returned parameters on
the basis that anything it knows about and is interested in it will
process, any unknown/unexpected state ids it will ignore (and for a
vanilla Sigcomp, receiving an acked_state_id for an item of state
previously created at the remote at its instigation, that would count as
unexpected).

> item(s) is/are larger than the compartment SMS?

I would say, don't truncate it. Assign it to the compartment if you
must. Neither should any other state item be pushed out of SMS to create
space for the LAS. This isn't actually stated in SIGCOMP, nor is it
implied by the priority of -1, since the priorities are only used to
distinguish between *existing* items, e.g. a new low-priority item can
normally displace an old item of a higher priority (as described in
SIGCOMP 6.2 points 4 and 5)

Best regards, John

> Sent: 02 March 2006 10:37
> To: John Barber; [email-masked]
> On looking into this further, section 6.2 seems to confuse 
> things, depending on what you read into it.  However, I think 
> RFC3320 is pretty clear.  Let's see if I can summarise this 
> and generate a list of questions to be answered.
> 
> RFC3320 discusses 'locally available state' (LAS):  all the 
> discussion about advertisements refers to  LAS.  There is no 
> mention of advertising anything other than LAS.  LAS is a 
> potentially confusing term, but (I
> think) well defined -- it is state that is available at a 
> given endpoint (rather than just a compartment).
> 
> According to Section 3.3.3. examples of LAS are dictionaries 
> and bytecode.  Nothing is said about their lifetime.  
> However, for them to be 'locally available' they must exist 
> within the endpoint, so why would they ever be deleted?
> 
> As you point out, Section 6.2 allows for the possibility of 
> LAS items to be mapped to a compartment.  However, I think 
> that the point 6.2 is making is: *if you do this*, then you 
> must use retention priority 65535 to avoid interference with 
> state requests.  I do not think it is suggesting that this is 
> what you *should* do.  (The only reason I can think of for so 
> doing is to control which local state is advertised to a 
> Question: If you *do* map LAS items to a compartment, what 
> happens if the item is larger than the SMS for the 
> compartment?  e.g. SIP/SDP static dictionary (3.5kbyte) with 
> 2kbyte compartment?  Does this imply that the dictionary is 
> truncated to fit the compartment?!
> 
> - that a piece of state with that identifier is available at 
> the peer endpoint;
> - that if the state is mapped to a compartment, this will not 
> interfere with state-creation requests;
> - that if it recognises the advertised state ID, it can make 
> use of the state; and
> - that unless it knows otherwise, the state will persist 
> outside of the compartment.
> 
> 
> RFC3321 brings in the concept of advertising shared_state_ids 
> (5.2) and acked_state_ids (5.1).
> 
> Shared_states are well defined - they are stored within a 
> compartment; created at priority 65535; and if the receiving 
> endpoint doesn't use shared-mode, then their advertisement 
> doesn't affect interoperability.
> 
> An acked_states_id seems to identify a piece of state that 
> the remote endpoint has requested to be created.  Performing 
> such an advertisement seems to imply that either:
> - the use of the advertisement has been updated by an 
> informational draft; or
> - in advertising it, the endpoint has turned the piece of 
> state into LAS (either within the compartment or not).
> 
> The receiver of such an ack needs to infer whether or not the 
> state is mapped to a compartment and what its lifetime is.  
> However, if it *is* viewed as LAS, then we note that LAS 
> *must* have priority 65535.
> 
> Question: what does a vanilla RFC3320 implementation assume 
> on receipt of such an advertisement?
> ii)  that the requested state-create matched an already 
> existing piece of LAS (surely only for well-known state 
> items, e.g. bytecode?!);
> iii) assume that the other endpoint has turned this state 
> into LAS (at priority -1);
> conservative. (iii) makes no sense -- there is no indication 
> within RFC3320 that this could happen.  (ii) may also be 
> reasonable, in certain cases.
>  
> 
> In summary:
> 
> * An endpoint advertising non shared-mode local state may map 
> it to, and subsequently delete it from, a compartment but 
> should not delete it altogether;
> 
> * What should an 'RFC3320 only' implementation assume about 
> the advertisement of the state id of state it requested to be created?
> 
> * What *are* the allowed semantics of state advertisements; 
> where should they be defined; and can they cause 
> incompatibilities with base RFC3320 (see previous question)?
> 
> And in answer to your question about why the authors allowed 
> it; I can only assume that it is because the mechanism is 
> needed for shared mode and both RFCs were written at the same 
> time.  The authors are, of course, welcome to clarify this. :-)
> 
> Best regards,
> 
> Abbie 
> 
> > I like your interpretation of RFC3320 on this one. My 
> initial reading 
> > of the spec was that an implementation could choose to implement 
> > locally-available state items as being mapped to compartments, and 
> > that this could lead to the locally-available state item 
> being "pushed 
> > out of" the compartment and suddenly becoming unavailable. 
> In the SIP 
> >       to the compartment, sufficient items of state created by the 
> > same
> >    endpoint.  The special state_retention_priority of 65535 is 
> > reserved
> must always 
> > be
> compartment and 
> >       items may be created by several different compartments, so a 
> > state
> > The above could be taken to mean that an item of locally-available 
> > state freed from a compartment should be physically deleted - after 
> > all, it may be "no longer required by any compartment". 
> That is how I 
> > initially understood it.
> > 
> > 6.2 in your new Implementer's Guide 10.3, clarifying the point that 
> > when a locally-available state item is freed from a 
> compartment, the 
> > state item itself should not be deleted.
> > 
> within the 
> > >    of any compartment and that, once they have been advertised 
> > > within a
> > >    compartment to a remote compressor, they will be available for 
> > > use by
> > What SIGCOMP actually seems to be saying is that locally available 
> > state items *may* be within the SMS of a compartment, but 
> the priority 
> > rules ensure that they are first to drop out of the 
> compartment, so as 
> > not to conflict with other state items in the compartment. Though I 
> > have to say I don't really understand the intention of this design. 
> > What is the possible advantage of mapping a locally-available state 
> > item to a compartment, and why did the SIGCOMP authors allow it?
> > 
> > Regards, John
> >  
> > 
> request is 
> within the 
> > >    of any compartment and that, once they have been advertised 
> > > within a
> > >    compartment to a remote compressor, they will be available for 
> > > use by
> semantics of

---

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 3 Mar 2006 08:46:24 -0000

Hi John,

> I think the key to this

Yes, the key is that state is being stored in one endpoint without the
knowledge of the other endpoint (under whose control state creation
usually is).  The only way this can happen though is with state of
priority -1 hence the discussion of state priority -1.  I'll see if I
can make the text a bit clearer.

Thanks too for the comment about SM1, BC etc - I'll add some
clarification.

Best regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 3 Mar 2006 14:13:55 -0000

Hi John, all,

I don't want to halt this discussion because I think it is important
that we get to the bottom of these issues.  At the same time, the
deadline for draft submission is Monday.

Consequently, I have tried to summarise where I think we are in an
updated version of the draft which is available at
<http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-impl-guide-06.tx
t>.  

It also includes updated text on the requested feedback discussion
(section 9.2) and clarification of the section on 65535 state (section
5.3).

Any comments or changes to the draft that it is important to make before
submission greatly appreciated.  If I don't receive any comments by 10am
GMT on Monday, I will submit the draft as it is now.

I hope that the summary in the draft (including editor's notes which
will need further discussion and conclusion) addresses the points in
this email (including your final comment about 65535 state being able to
push other state out of the compartment - here is a statement in 3321
about this but you're right, it isn't stated in 3320!).  

Continuation of the discussion to reach a conclusion, also greatly
appreciated :-)

Best regards,

Abbie

> Sent: Thursday, March 02, 2006 10:30 PM
> compartments, and 
> locally-available 
> point that 
> available for 
> available for

---

From: "John Barber" <[email-masked]>
Date: Fri, 3 Mar 2006 15:12:13 -0000

Hi again Abbie, all,

That is a good summary of the discussion so far.

Just a few typos which I think you would want to correct before
submission (all in Section 10.3 p14):

"this some definition of this mapping"
"SigComp Extended [2] makes use of the meant in two ways"
"and with the clarification on creation
   of creation of state with minimum retention priority provided in
   Section 5.3)" ["on creation of creation" and unmatched closing
parenthesis]

Other than that, no further comments from me :-)

Best regards, John

> Sent: 03 March 2006 14:14
> I don't want to halt this discussion because I think it is 
> important that we get to the bottom of these issues.  At the 
> same time, the deadline for draft submission is Monday.
> 
> Consequently, I have tried to summarise where I think we are 
> in an updated version of the draft which is available at 
> It also includes updated text on the requested feedback 
> discussion (section 9.2) and clarification of the section on 
> 65535 state (section 5.3).
> 
> Any comments or changes to the draft that it is important to 
> make before submission greatly appreciated.  If I don't 
> receive any comments by 10am GMT on Monday, I will submit the 
> draft as it is now.
> 
> I hope that the summary in the draft (including editor's 
> notes which will need further discussion and conclusion) 
> addresses the points in this email (including your final 
> comment about 65535 state being able to push other state out 
> of the compartment - here is a statement in 3321 about this 
> but you're right, it isn't stated in 3320!).  
> 
> Continuation of the discussion to reach a conclusion, also 
> greatly appreciated :-)
> 
> Best regards,
> 
> Abbie
> 
> 
> > > bytecode.  Nothing is said about their lifetime.
> > > However, for them to be 'locally available' they must 
> exist within 
> > > the endpoint, so why would they ever be deleted?
> > 
> > > Question: If you *do* map LAS items to a compartment, 
> what happens 
> > > if the item is larger than the SMS for the compartment?  e.g. 
> > > SIP/SDP static dictionary (3.5kbyte) with 2kbyte 
> compartment?  Does 
> > > this imply that the dictionary is truncated to fit the 
> compartment?!
> > 
> > Which prompts the question: IF, at state creation time, LAS doesn't 
> > obey the normal compartment rules for state items, and, during its 
> > lifetime, it does not effectively occupy space in the compartment 
> > (because it has priority -1 so will not impinge on other 
> state items), 
> > and, when it is removed from the compartment, does not behave like 
> > other state items associated with a compartment, in that it 
> will never 
> > be physically deleted, THEN, in what sense can LAS really 
> be said to 
> > be mapped to the compartment? I would suggest that the 
> whole concept 
> > of mapping LAS to a compartment serves only to generate 
> confusion, but 
> > I agree with your approach which is to clarify the possible harmful 
> > interpretations as being the wrong ones.
> > 
> > > An acked_states_id seems to identify a piece of state that the 
> > > remote endpoint has requested to be created.  Performing such an 
> > > advertisement seems to imply that either:
> informational 
> state into 
> > > LAS (either within the compartment or not).
> > 
> > to be done through the END-MESSAGE/requested feedback/returned 
> > feedback path. There is no suggestion that sending such an 
> automatic 
> > > Question: what does a vanilla RFC3320 implementation assume on 
> > > receipt of such an advertisement?
> > > ii)  that the requested state-create matched an already existing 
> > > piece of LAS (surely only for well-known state items, e.g. 
> > > bytecode?!);
> > > RFC3320 that this could happen.  (ii) may also be reasonable, in 
> > > certain cases.
> > 
> > previously created at the remote at its instigation, that 
> would count 
> > as unexpected).
> > 
> > must. Neither should any other state item be pushed out of SMS to 
> > create space for the LAS. This isn't actually stated in 
> SIGCOMP, nor 
> > is it implied by the priority of -1, since the priorities are only 
> > used to distinguish between *existing* items, e.g. a new 
> low-priority 
> > item can normally displace an old item of a higher priority (as 
> > described in SIGCOMP 6.2 points 4 and 5)
> > 
> > Best regards, John
> > 
> > 
> > 
> > > depending on what you read into it.  However, I think RFC3320 is 
> > > pretty clear.  Let's see if I can summarise this and 
> generate a list 
> > > of questions to be answered.
> > > 
> > > discussion about advertisements refers to  LAS.  There is 
> no mention 
> > > of advertising anything other than LAS.  LAS is a potentially 
> > > confusing term, but (I
> > > think) well defined -- it is state that is available at a given 
> > > endpoint (rather than just a compartment).
> > > 
> > > bytecode.  Nothing is said about their lifetime.
> > > However, for them to be 'locally available' they must 
> exist within 
> > > the endpoint, so why would they ever be deleted?
> > > 
> > > As you point out, Section 6.2 allows for the possibility of LAS 
> > > items to be mapped to a compartment.  However, I think that the 
> > > point 6.2 is making is: *if you do this*, then you must use 
> > > retention priority 65535 to avoid interference with state 
> requests.  
> > > I do not think it is suggesting that this is what you 
> *should* do.  
> > > (The only reason I can think of for so doing is to control which 
> > > local state is advertised to a given endpoint and for how long.)
> > > 
> > > Question: If you *do* map LAS items to a compartment, 
> what happens 
> > > if the item is larger than the SMS for the compartment?  e.g. 
> > > SIP/SDP static dictionary (3.5kbyte) with 2kbyte 
> compartment?  Does 
> > > this imply that the dictionary is truncated to fit the 
> compartment?!
> > > 
> > > - that a piece of state with that identifier is available at the 
> > > peer endpoint;
> > > - that if it recognises the advertised state ID, it can 
> make use of 
> > > the state; and
> > > endpoint doesn't use shared-mode, then their 
> advertisement doesn't 
> > > affect interoperability.
> > > 
> > > An acked_states_id seems to identify a piece of state that the 
> > > remote endpoint has requested to be created.  Performing such an 
> > > advertisement seems to imply that either:
> informational 
> state into 
> > > LAS (either within the compartment or not).
> > > 
> > > The receiver of such an ack needs to infer whether or not 
> the state 
> > > is mapped to a compartment and what its lifetime is.
> > > Question: what does a vanilla RFC3320 implementation assume on 
> > > receipt of such an advertisement?
> > > ii)  that the requested state-create matched an already existing 
> > > piece of LAS (surely only for well-known state items, e.g. 
> > > bytecode?!);
> > > RFC3320 that this could happen.  (ii) may also be reasonable, in 
> > > certain cases.
> > >  
> > > 
> > > In summary:
> > > 
> > > * An endpoint advertising non shared-mode local state may 
> map it to, 
> > > and subsequently delete it from, a compartment but should 
> not delete 
> > > it altogether;
> > > 
> > > * What *are* the allowed semantics of state advertisements; where 
> > > should they be defined; and can they cause incompatibilities with 
> > > base RFC3320 (see previous question)?
> > > 
> > > And in answer to your question about why the authors 
> allowed it; I 
> > > can only assume that it is because the mechanism is needed for 
> > > shared mode and both RFCs were written at the same time.  The 
> > > authors are, of course, welcome to clarify this. :-)
> > > 
> > > Best regards,
> > > 
> > > Abbie
> > > 
> advertised 
> advertised