RE: [rohc] ROHC-FN

["Price, Richard" <richard.price@roke.co.uk>]

> Hi All,
> We have seen the new release of ROHC-FN. May I know the
> reason for the change that "updated_context" has removed?

Hi William,

The term "updated_context" has been removed because it implied
(misleadingly) that the compressor must store exactly two
copies of the context: the "old" context containing the fields
from the previous header in the flow, and the "updated" context,
which is created using fields from the header currently being
compressed.

In fact, for robustness, the compressor context will typically
store a history of field values from several previous headers
in the flow.  When a new header is successfully compressed, its
field values will be added to the ones already contained in
the context (the number of values stored for each field depends
on how much robustness you need).

However, the above is only important if you're worried about
robustness in the first place.  For a non-robust implementation,
it's fine to store just the "old" and the "updated" context at
the compressor.

> In the new release, the encoding method FIELD updates the
> context with the new field value as it does compression but
> there is no rollback action of updating the context when the
> compression/decompression may fail. How to understand it?

Rollback is handled as before - if compression or decompression
fails for whatever reason, then the context is not updated to
contain the field values from the current header.

> In addition to the description on the compression procedures
> of the pre-defined, basic and extended library of all the
> encoding methods in the draft,  should we need its
> counterpart the decompression  procedures to complete the
> understanding of the encoding methods that is useful to those
> who try to write the encoding algorithm of the profile such
> as ROHC-TCP?

For the basic encoding method library of Chapter 5, it might
be useful to provide the decompression procedures as well as
the compression procedures.  Obviously it's possible to
decompress headers just by "reversing" the compression
process, but writing out how to do this explicitly would
probably be helpful in making the encoding methods easier to
implement.

For the extended encoding method library of Chapter 6, there's
no need to provide separate procedures for compression and
decompression.  This is because all of the encoding methods in
Chapter 6 are defined using ROHC-FN itself, by applying one or
more of the basic encoding methods from Chapter 5.  For example:

label (#n,$name)   ::=   field (n) 
                         map (name, Null, Field_Value)  
                         map (Field_Value, name, Null) 

This means that the "label" encoding method is defined by a
single application of the "field" encoding method, plus two
applications of the "map" encoding method.  This definition
works for both compression and decompression.  If you want to
use "label" to compress a field, you simply invoke the
compression versions of the "field" and "map" encoding methods.
If you want to use it for decompression, you invoke the
decompression versions of the two encoding methods.

Regards,

Richard
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc