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

["Price, Richard" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, February 21, 2002 10:29 AM
> To: '[e-mail]'
> 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. 
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc
>