Subject: [rohc] Sigcomp Implementer's Guide

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 17 Jun 2003 09:29:43 +0100

Hi All,

There have been some suggestions for additions to the implementer's guide so here's the proposed text.  Any comments and other additions gratefully received.  I'm planning to resubmit the draft before the -0n deadline so would appreciate comments before the end of this week please - this gives time to make changes and agree them on the list before the deadline.

Clarification that STATE-FREE is compartment specific:
2nd paragraph added to section 3.2:

"The STATE-FREE instruction can only free state in the compartment
   that corresponds to the message being decompressed.  Attempting to
   free state either from another compartment or that is locally
   available has no effect."

Summary of the outcome of discussion about dynamic DMS and SMS updates:

"8. Dynamic Update of Resources

   Decompressor resources such as SMS and DMS can be dynamically updated
   at the compressor by use of the SMS and DMS bits in returned
   parameters feedback (section 9.4.9).  Changing resources dynamically
   (apart from initial advertisements for each compartment) is not
   expected to happen very often.

   If additional resources are advertised to a compressor then it is up
   to the implementation at the compressor whether or not to make use of
   these resources.  For example, if the decompressor advertises 8k SMS
   but the compressor only has 4k SMS then the compressor may choose not
   to use the extra 4k (e.g. in order to monitor state saved at the
   decompressor).  In this case, there is no synchronisation problem.
   The compressor must not use more than the most recently advertised
   resources.  Note that the compressor SMS is unofficial (enables
   compressor to monitor decompressor state) and is separate from the
   SMS advertised by the decompressor.

   Reducing the resources has potential synchronisation issues and so
   should not be done unless absolutely necessary.  If this is the case
   then the memory should not be reclaimed until the remote endpoint has
   acknowledged the message sent with the advertisement.  If state must
   be deleted to accommodate a reduction in SMS then both endpoints
   should delete it according to the state retention priority (section
   6.2).  The compressor should use up to the amount of resources most
   recently advertised."

There was also a suggestion about clarification that state too large for the available SMS in shared mode should be truncated (and the hash computed appropriately).  
IMHO this is no different from any other state that is too large and is clear in RFC 3320.  Does anyone think this is a useful clarification to include?

Best regards,

Abbie

Abbie Surtees
Engineer
Internet Applications and Mobility
Roke Manor Research Ltd
Tel:   +44 (0) 1794 833131

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 23 Jun 2003 11:15:44 +0100

Hi All,

As I've not received any comments about the proposed additions to the
SigComp Implementer's Guide (see below, posted 17/6) then I assume there are
no objections.  

If anyone has any comments (positive or negative) please send them to the
list by 12pm GMT tomorrow, after which time I will submit the draft.

Cheers,

Abbie

>
>Hi All,
>
>There have been some suggestions for additions to the 
>implementer's guide so here's the proposed text.  Any comments 
>and other additions gratefully received.  I'm planning to 
>resubmit the draft before the -0n deadline so would appreciate 
>comments before the end of this week please - this gives time 
>to make changes and agree them on the list before the deadline.
>
>There was also a suggestion about clarification that state too 
>large for the available SMS in shared mode should be truncated 
>(and the hash computed appropriately).  
>IMHO this is no different from any other state that is too 
>large and is clear in RFC 3320.  Does anyone think this is a 
>useful clarification to include?
>
>Best regards,
>
>Abbie
>
>Abbie Surtees
>Engineer