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

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Thu, 21 Feb 2002 11:29:05 +0100

Hi,

As I indicated in a previous mail the two drafts are not fully compliant yet. This is a proposal for solving this.

In my comments to Miguel I explained why we need to signaling the state identifier length (ID length) in each SigComp message, and how the remaining bits can be used for a new basic SigComp message format. 

The reasons for having the ID-length in each SigComp message are the following:
* SigComp do not know the length of the state identifier prior to the capability announcement.
* As SigComp does not separate flows, SigComp needs to carry the hash length (ID length) for each SigComp message.  

The remaining 4-bits can be used for something else, and below is a proposal for the new SigComp basic Message format:

  0   1   2   3   4   5   6   7 
+---+---+---+---+---+---+---+---+ 
|  MT   |Reserv.|    ID length  | 
+---+---+---+---+---+---+---+---+ 
|                               | 
:   state_identifier (n-bytes)  :  
|                               | 
+---+---+---+---+---+---+---+---+ 
|                               | 
:    Remaining UDVM bytecode    : 
|                               | 
+---+---+---+---+---+---+---+---+ 

Instead of reserving a state_identifier for indication of what type of message this is, a Message Type is included. 

To avoid making changes to the UDVM instructions according to message:
http://www.cdt.luth.se/rohc/msg03674.html
and to make use of shared compression it is necessary for an endpoint to know whether its remote endpoint understands the format of the Returned feedback as depicted in Figure 7 of draft-ietf-rohc-sigcomp-extended-01.txt or not. 

Therefore I propose the following changes to the two sigcomp-drafts.

******** changes to draft-ietf-rohc-sigcomp-04.txt *******

Section 4.2. 

The basic SigComp message format is changed to the format above.

* Message Type
MT = '00' --- "ordinary compressed message"
MT = '01' --- "SigComp request message"
MT = '10' --- "SigComp Capability announcement message"
MT = '11' --- "Reserved"

* Reserv.
Bits 2 and 3 is reserved and is set to '00'

* Id length
The length of the state_identifier for this SigComp message
'0000' - 1 byte state_identifier
'0001' - 2 bytes state_identifier
...
'1111' - 16 bytes state_identifier

******** Changes to draft-ietf-rohc-sigcomp-extended-01.txt *******

Section 6.1.

The basic SigComp message format is changed to the format above.

The reserved bit 2, is used to indicate to the remote endpoint the understanding of the Returned feedback format as depicted in Figure 7.  Thus, an endpoint sets bit 2, in every sent SigComp message to indicate the understanding of the Returned feedback format. If two communicating end-points both sets bit 2. They MUST use the Returned feedback format as depicted in Figure 7. In any other case must no assumption be drawn about the format of the Returned feedback format.

Note: Setting bit 2 does not mandate an endpoint to use SigComp-extended, but only that it understands the Returned feedback format and will use the 'r' and 'b' etc. bits accordingly.
 
Figure 7, is changed to:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |r|b|        n              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        id_length 1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :        id_value_1         :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        id_length 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :        id_value_2         :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            :         :
            :         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        id_length n        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :        id_value_n         :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :    Additional feedback    :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Additional feedback is an item of feedback data that has successfully returned from the remote endpoint.

****************

BR
/Hans H

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

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 21 Feb 2002 12:41:15 -0000

Hi Hans,

I must confess, from an IPR perspective I can't see the difference
between your proposal and the proposal I made in
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00020.html.

The 'reserved' bits in your proposed header can be set to indicate
support for certain optional mechanisms, for example the mechanisms
proposed in sigcomp-extended. A separate bit or bit pattern is
reserved for each mechanism (e.g. you propose to reserve bit 2 for
sigcomp-extended).

However, this is precisely the function of the "identifier list" that
I proposed in my previous email. Different identifiers are reserved
for each optional mechanism (one per well-known decompression algorithm,
one for sigcomp-extended and so on). By sending an identifier an endpoint
indicates support for the corresponding mechanism.

The only difference I can see is that the identifier list has support for
variable-length identifiers of up to 16 bytes rather than a fixed 2-bit
identifier as you currently propose. However I can't believe that merely
reducing the size of each identifier removes the IPR concerns.

This situation worries me because we currently don't have any way of
switching on support for sigcomp-extended at all. In your opinion my
proposal for adding support has IPR concerns, and in my opinion your
alternative proposal suffers from these same IPR concerns. If we can't
resolve this issue then we'll be forced to rely on downloading sigcomp-
extended as bytecode.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 10:29 AM
> To: [email-masked]'
> Subject: [rohc] SigComp Message and (extended) Returned feedback.
> 
> 
> Hi,
> 
> As I indicated in a previous mail the two drafts are not 
> fully compliant yet. This is a proposal for solving this.
> 
> In my comments to Miguel I explained why we need to signaling 
> the state identifier length (ID length) in each SigComp 
> message, and how the remaining bits can be used for a new 
> basic SigComp message format. 
> 
> * As SigComp does not separate flows, SigComp needs to carry 
> the hash length (ID length) for each SigComp message.  
> 
> The remaining 4-bits can be used for something else, and 
> below is a proposal for the new SigComp basic Message format:
> 
>   0   1   2   3   4   5   6   7 
> Instead of reserving a state_identifier for indication of 
> what type of message this is, a Message Type is included. 
> 
> and to make use of shared compression it is necessary for an 
> endpoint to know whether its remote endpoint understands the 
> format of the Returned feedback as depicted in Figure 7 of 
> draft-ietf-rohc-sigcomp-extended-01.txt or not. 
> 
> The reserved bit 2, is used to indicate to the remote 
> endpoint the understanding of the Returned feedback format as 
> depicted in Figure 7.  Thus, an endpoint sets bit 2, in every 
> sent SigComp message to indicate the understanding of the 
> Returned feedback format. If two communicating end-points 
> both sets bit 2. They MUST use the Returned feedback format 
> as depicted in Figure 7. In any other case must no assumption 
> be drawn about the format of the Returned feedback format.
> 
> Note: Setting bit 2 does not mandate an endpoint to use 
> SigComp-extended, but only that it understands the Returned 
> feedback format and will use the 'r' and 'b' etc. bits accordingly.
>  
> Figure 7, is changed to:
> 
> The Additional feedback is an item of feedback data that has 
> successfully returned from the remote endpoint.
> 
> ****************
> 
> BR
> /Hans H
>

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Fri, 22 Feb 2002 16:09:22 +0100

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