Subject: RE: [rohc] RE: The 'b'-bit

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Sat, 16 Mar 2002 12:19:22 +0100

> > > > I'm asking this because this thread started as case b) 
> > > > (see below), but it seems what you said above is about a)?
> > > > 
> > > > endpoint 1                     endpoint 2
> > > >                  m(S0)
> > > > map M to S1  ------------>    create M, and S1=S0+M
> > > > 
> > > >         announcement: b=0, shared_id=M
> > > >            <--------------------
> > > 
> > > I think that the above diagram is missing the 's' bit, which 
> > > is sent in the first message to indicate that Endpoint 1 
> > > has saved message M as
> > > state. 
> > 

> I'm totally lost. Do you mean 'r' bit? But it has been replaced
> by other approached according to email exchanged between Hans and you,
> Right?
> https://www1.ietf.org/mail-archive/working-groups/rohc/current
> /msg00152.html 

Yes, it should be the 'r' bit. The 's' bits belongs to the example Extended SigComp message and is there to signal whether this SigComp message contains a shared identifier or not.

What has been discussed is how to remove the 'r' and 'b' bits from Figure 7 of sigcomp-extended-02, without losing the functionality they provide.

The 'r' bit can be removed if the MD5 instruction is modified according to:
https://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00152.html 

The 'b' bit may be removed as it can never be set to 0 (if this is what our discussion will end up in). What does this mean actually?
Well, first of all the 'b' bit is an optimisation for explicitly acking a state which "corresponding" decompressed message is used in the compression process. 
I'll reuse Zhigang's figure (slightly changed) in order to clarify this. 

endpoint 1                     endpoint 2
                  m(S0),'r=1'
  map M to S1  ------------>    create M, and S1=S0+M
                                   
                                   | 
    					id_value = S_M  ('r-bit removed') 
                                   |
	                             v
 
         announcement: 'b=1', shared_id=S_M
            <--------------------

If set the 'r' bit indicates that an uncompressed version of this compressed message was saved as a state (S_M) at endpoint 1, and that this state can be accessed by the UDVM at endpoint 1. The 'r' bit can be removed from the extended announcement information as it is replaced with id_value = S_M in the announcement information from the UDVM at endpoint 2 to the compressor at endpoint 2.

Now if the compressor at endpoint 2 makes use of S_M in the compression it will include shared_id = S_M in the extended SigComp message. Instead of including both shared_id and the acked_id = S1 in the SigComp message from endpoint 2 to endpoint 1 the intention with the b-bit was to save the space for the acked_id = S1. Thus, the shared_id = M and 'b-bit = 1' would implicitly acknowledge the creation of state S1 at endpoint 2.

According to SigComp-05 as Richard indicates, the compressor at endpoint 2 will never get the announcement for id_value = S_M if not S1 is created at endpoint 2. Thus, the b-bit can never be set to zero and may possible be excluded from the 
announcement of Figure 7 in Sigcomp-extended-02.

BR
/Hans H

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