Subject: [rohc] Local state advertisements and the implementer's guide

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 30 Aug 2006 16:12:15 +0100

Hi All,

Back in February and March we were having a discussion about locally
available state items and the semantics of their advertisement.

We didn't conclude the discussion for the last version of the
implementer's guide so I included an editor's note.  The discussion
seems to have stalled at that point, so here's where I think we are, and
a proposal for how to progress.

(The previous email thread starts with the third part of this email
<http://www1.ietf.org/mail-archive/web/rohc/current/msg04146.html> and
continues till Fri 3rd March and the resulting ID is here
<http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-
06.txt> (section 10.3).)

1) The definition of advertisement of locally available state (such as
dictionaries and well-known pieces of bytecode) is relatively clear in
RFC 3320.  The assumptions are that:

  a) such state is local to the endpoint and will not be deleted
(ignoring I-bit, see below)

  b) such state does NOT count towards the SMS of a compartment

[as an implementation choice, locally available states may be mapped
onto compartments, but this must not affect (a) and (b), above.]

2) Section 6.2 of RFC 3320 discusses mapping locally available state to
a compartment.  I believe that this concept (as specified in RFC 3320
only) is not well-defined (e.g. does it count towards SMS, if so, how
does the I-bit work? If not, why define the use of minimum retention
priority?)  

Can anyone (authors?) explain to me the intention of this for a basic
(RFC 3320) implementation?

If not, then I suggest that the clarification for the implementer's
guide is that the concept of mapping locally available state to a
compartment can only be considered as an implementation choice and one
that cannot interfere with the statements in (1), above.

A locally available state item that is advertised can be assumed to be
available for the lifetime of the compartment.

3) If the advertised state is to be used in any other way, then its use
and semantics (including the concept of mapping state to a compartment)
must be fully and completely specified.

There are currently three uses (or proposed uses) of state
advertisements:

(a) Shared-mode (defined in Section 5.2 in RFC 3321) -

I believe that shared-mode (as clarified by section 5.3 of the
implementer's guide) is well-defined, covering state-creation, priority,
state-advertisement and deletion rules within a specified compartment
mapping.

(b) Endpoint-initiated acks (defined in Section 5.1.2 in RFC 3321) -

Endpoint B advertises the hash of a state item that Endpoint A has
requested B to create (within a compartment).  Given these discussions,
this does not seem to be a well-defined concept.  There are various
possible interpretations at Endpoint A on receipt of the advertisement
from B:

   i) ignore it because the hash doesn't match any locally available
state known by the 
      endpoint (basic 3320);

  ii) as an 'ack', it simply means that B has successfully created the
state
     (this is a stronger statement than receipt of requested feedback,
which means only 
      that the message was successfully decompressed);

  iii) Endpoint B already has a piece of locally available state with
this hash, so
      creation has failed (not useful);

  iv) Endpoint B is treating the state in a manner similar to a piece of
locally 
      available state (i.e. increasing its lifetime)
       (whether the state still counts towards SMS at this point is
unclear).

(c) State lifetime extension (beyond compartment lifetime) 
    (from section 6.2 of
<http://tools.ietf.org/wg/rohc/draft-ietf-rohc-sigcomp-sip/draft-ietf-ro
hc-sigcomp-sip-02.txt>) -

This is similar to endpoint initiated acks but this document specifies
that advertisements mean that the endpoint will keep the state for an
unspecified amount of time beyond the closure of the compartment.

Since this clearly overlaps with (b), I believe this concept is also NOT
well defined.

My proposal for the implementer's guide is to clarify that:

*) For 'basic' RFC 3320 implementations locally available state is
   - not mapped to compartments
   - is local to the endpoint and persists for the duration of the
compartment
   - does not impact compartment SMS

*) SigComp 'extended' mechanisms may use state advertisements provided
that their use
   is clearly defined and does not conflict with any other usage

   - shared-mode is one such well-defined usage
     (although its definition in a non-standards-track document is still
rather odd!)

   - endpoint initiated acknowledgements should be further clarified.

The suggested clarification for the advertisement semantics with respect
to endpoint-initiated acks is as follows (this merges interpretations
ii) and iv); interpretation i) must always be valid):

"Where Endpoint A requests state creation at Endpoint B, Endpoint B may
subsequently advertise the hash of the created state item to Endpoint A.
This conveys to Endpoint A (i) that the state has been successfully
created within the compartment; and (ii) that the state will be
available for *at least* the lifetime of the state as defined by RFC
3320.  If the state is available at Endpoint B after it would be deleted
from the compartment according to RFC 3320, then the state no longer
counts towards the SMS of the compartment.  Since there is no guarantee
of such state being available beyond its normally defined lifetime,
endpoints should only attempt to access the state where NACK is
available."

This seems to allow for all currently proposed behaviours and does not
conflict with the basic RFC 3320 definition.

Finally, if this clarification is made in the implementer's guide, then
it is only addressing general SigComp behaviour.  If a stronger promise
of keeping state is wanted (e.g. beyond the end of the compartment) then
this can be specified in 'Sigcomp for SIP' or other equivalent documents
in the same way as the minimum DMS or support of a dictionary is
specified.

What do you think?  

Best regards,

Abbie

--
Abbie Surtees
Consultant Engineer
Roke Manor Research Ltd
+44 1794 833131 

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