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

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 28 Feb 2006 11:13:55 -0000

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

> 
> 
> > -----Original Message-----
> > 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
> > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 
> _______________________________________________
> 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: "John Barber" <[email-masked]>
Date: Tue, 28 Feb 2006 14:35:04 -0000

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

> From: Surtees, Abigail [mailto:[email-masked]] 
> Sent: 28 February 2006 11:14
> To: [email-masked]
> Subject: RE: [rohc] SigComp Implementer's guide - it's that time again
> 
> 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:
> > 
> 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Surtees, Abigail
> > > 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: Tue, 28 Feb 2006 14:51:25 -0000

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

> From: John Barber [mailto:[email-masked]] 
> Sent: 28 February 2006 14:35
> To: Surtees, Abigail; [email-masked]
> 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:
> 
> *************
> 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
> 
> 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:
> > > 
> > 
> >    this feedback in every message sent within that 
> compartment until 
> > it
> >    does not equal zero but the Q flag indicating the 
> presence/absence 
> > of
> >    that the message can be decompressed using the resources 
> available 
> > at
> >    of any compartment and that, once they have been 
> advertised within 
> > a
> >    compartment to a remote compressor, they will be 
> available for use 
> > by

---

From: "John Barber" <[email-masked]>
Date: Tue, 28 Feb 2006 15:38:39 -0000

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
> advertised within a

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

> compartment until it
> presence/absence of
> available at
> advertised within a