RE: [rohc] SigComp Message and (extended) Returned feedback.

["Hans Hannu (EPL)" <[e-mail]>]

Hi Richard and others,

To support shared compression I agree with you that we need to announce its support at some time instance. For explicit acknowledgements on the other hand we could add the State Create instruction as I explained in http://www.cdt.luth.se/rohc/msg03674.html . 
However, it may be simpler to allow for this to be announced in a capability announcement message, as we need to do that for shared compression anyhow.

So, the issue relates to announcement of supported features, e.g. a SigComp endpoint may announce that it supports a decompression algorithm without that the compression needs to upload the corresponding UDVM bytecode.
Depending on how we write the text, this might raise some IPR considerations. If we can make it absolutely clear that this capability announcement mechanisms with identifiers is only used to advertise the support of well known features, e.g. a well-known UDVM decompression algorithm. Thus, what may be in this capability announcement block is pre-defined identifiers and not any identifiers for state(s) that are created during the SigComp "session". Then I think this solves at least my IPR concerns. 

I therefore suggest the following changes to the drafts to make the sigcomp drafts synchronized. I think also this would make  shared compression and explicit acknowledgements possible even if the announcement is not done before the compression actually starts.

********** SigComp-04 *****
Section 6.3, Figure 5.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |       UDVM_version        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    overall_memory_size    |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |      cycles_per_bit       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    cycles_per_message     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |            n              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        id_length 1        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           |
      :        id_value_1         :
      |                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            :         :
            :         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        id_length n        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           |
      :        id_value_n         :
      |                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 5: Capability announcement block

"The 'Length' field specifies the length of the entire capability announcement block. The 'n' field indicates how many identifiers that are present in the block. The 'id_length x' field specifies the length of the 'id_value_x' field. The identifiers, which are reserved numbers for well-known features, may be used to announce support for the well-known features, e.g. UDVM decompression algorithms that are supported by the SigComp endpoint which this capability announcement block originates from. Thus, a compressor may choose to use one of the already supported UDVM decompression algorithms to avoid a UDVM decompressor algorithm upload."

- The text in section 6.3 regarding Requested and Returned feedback are removed.

********** SigComp-extended *****

- Figure 5 in Sigcomp extended is also changed accordingly to the figure above. 
- Figure 6 in SigComp extended is removed.
- Figure 7 in SigComp extended is changed to the figure below.
  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |       UDVM_version        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    overall_memory_size    |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |      cycles_per_bit       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    cycles_per_message     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |            n              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        id_length 1        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           |
      :        id_value_1         :
      |                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            :         :
            :         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        id_length n        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           |
      :        id_value_n         :
      |                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
      |r|b|       Reserved        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

  Figure 7. Extended operations feedback format.  

"When a SigComp message is not regarded as a capability announcement message, the END-MESSAGE instruction does not actually point to the capability announcement location but rather to a feedback location with the feedback format block as depicted in Figure 7. The id_length(s) and id_value(s) corresponds to the hash_length and hash_value for state(s) that have been established at the remote end-point due to received SigComp messages and may be used for compression, i.e. these are acknowledgements for established state. "

- The 'r' and 'b' are to be interpreted as in sigcomp-extended-01.txt
- An identifier value for explicit acknowledgements/shared compression should also be reserved.
*********************

I hope this will solve our major issues so that we can update the draft once more before the IETF-meeting.

BR
/Hans H



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