Subject: [rohc] RE: Clarifications for the Implementer's guide

From: "Peter Kremer (ETH)" <[email-masked]>
Date: Wed, 12 Jun 2002 14:03:13 +0200

Hi,

Thanks for your reply, Abbey.

> This is a good question.  The context management of CSRC 
> lists seems to be completely separate from the main context 
> management.  This question seems to encompass others. 
> 
>  From 5.8.2.1:
> 
>        In U/O-mode, curr_list is inserted into the sliding window
>        together with its generation identifier if the 

I think you refer to a wrong section, 5.8.2.1 is about reference based compression, which differs from table-based compression. Anyway, I agree that Translation table management is different.

> Should translation table entries sent in a UO-1-ID ext 3 
> count towards L (at the compressor)/update the table (at the 
> decompressor) or not?

I think the answer is yes to both questions. The compressor has to increment Counter because of section 5.8.1.2 ("Counter is incremented by 1 whenever an (Index, item) pair is sent."). The decompessor also has to update the table in order to successfully decompress the packets.

> I think a second point of discussion was that of 
> acknowledgements and CSRC lists.  In O-mode a compressor 
> receiving an acknowledgement can stop sending gen-id's early 
> as with acknowledgements of the main update packets.  
> However, the translation table in U/O mode stores only the 
> number of times a particular entry has been sent (5.8.1.2) 
> (whereas R mode stores the SNs so that entries can be 
> acknowledged (5.8.1.1)).  This means that even if an entry is 
> acknowledged the compressor will still send the full 
> information because as far as the translation table is 
> concerned the entry hasn't yet been sent enough times to be 
> sure that the decompressor has it.

I'm afraid I don't understand it. RFC 3095, section 5.8.1 says that the compressor has to send the list until it gains enough confidence that the decompressor has learnt the mapping. It can be done by sending the list L times in U/O-mode and by receiving an acknowledgement in R-mode. But - as I remember - the compressor will never receive an acknowledgement in O-mode for type 0 and 1 packets because only STATIC-NACK or NACK can be sent, according to section 5.4.2.2 (Feedback logic in O-mode).

Best regards,
Peter

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Wed, 12 Jun 2002 23:56:27 +0100

Hi Peter, all...

I think that there is one key question here, and a couple of others that 
fall out from that.

The main question relates to the fact that, currently, the 'context 
management' for list-based compression appears to be quite disassociated 
with the general ROHC context management.  So -- should they be 
separate, or not?

This gives rise to the original question that you posed: if a gen_id is 
quoted for a list in a UO-1 + Ext-3 packet, what happens?

(In fact, of course, we need to specify the decompressor behaviour.  Any 
compliant compressor then has to act in a manner consistent with this.)

I'll return to this question shortly!  But first...

The table-based compression also fits into this category.  This is the 
question that Abbie posed about whether updates sent in UO-1 + Ext-3 
packets count towards the value of 'L'.  Again, this is about whether 
such a packet is context updating.  According to the rules for UO-1 
packets, we should *not* update the context; but the table-based 
encoding description suggests that we *always* the table.

Ok, so, what does this mean?

Personally, I believe that the context data for list/table compression 
should be considered as part of the overall context.  Therefore, the 
overall context updating rules should apply.  (Partly this is because a 
list update can contain a lot of data, and in a UO-1 packet this is only 
protected with a 3-bit CRC).  So, I would suggest that any list encoding 
in a UO-1 packet (with Ext-3) is processed to decompress that header 
*but* does not create a new reference list (even if gen_id is given) and 
does not update any of the table references.

Finally, Abbie raised another (slightly disconnected) issue: that of 
acknowledgements of packets containing list/table compression data. 
(Clearly this does not apply in the case of UO-1 packets, since 
acknowledgements are not generated for these packets.  However, since I 
believe that these updates should probably be using UOR-2 packets, I 
think that this is a relevant issue!)
A UO-mode acknowledgment can short-circuit the sending of a list update 
multiple times.  However, it cannot prevent a table compression entry 
being sent 'L' times.  This just seems odd -- why can't an ack be used 
to indicate that a table entry has been accepted?
Unfortunately, this can't be changed without altering the data stored at 
the compressor for UO mode operation of table compression (since it is 
currently defined to only use a counter).

Hopefully this clarifies the questions (if not the answers ;-)

Mark.

 >
 >> This is a good question.  The context management of CSRC  lists
 >> seems to be completely separate from the main context  management.
 >>   This question seems to encompass others.
 >>
 >> From 5.8.2.1:
 >>
 >> In U/O-mode, curr_list is inserted into the sliding window together
 >>  with its generation identifier if the
 >>
 >
 > I think you refer to a wrong section, 5.8.2.1 is about reference
 > based compression, which differs from table-based compression.
 > Anyway, I agree that Translation table management is different.
 >
 >
 >> Should translation table entries sent in a UO-1-ID ext 3  count
 >> towards L (at the compressor)/update the table (at the  decompressor)
 >>  or not?
 >>
 >
 > I think the answer is yes to both questions. The compressor has to
 > increment Counter because of section 5.8.1.2 ("Counter is
 > incremented by 1 whenever an (Index, item) pair is sent."). The
 > decompessor also has to update the table in order to successfully
 > decompress the packets.
 >
 >
 >> I think a second point of discussion was that of  acknowledgements
 >>  and CSRC lists.  In O-mode a compressor  receiving an
 >> acknowledgement can stop sending gen-id's early  as with
 >> acknowledgements of the main update packets.   However, the
 >> translation table in U/O mode stores only the  number of times a
 >> particular entry has been sent (5.8.1.2)  (whereas R mode stores
 >> the SNs so that entries can be  acknowledged (5.8.1.1)).  This
 >> means that even if an entry is  acknowledged the compressor will
 >> still send the full  information because as far as the
 >> translation table is  concerned the entry hasn't yet been sent
 >> enough times to be  sure that the decompressor has it.
 >>
 >
 > I'm afraid I don't understand it. RFC 3095, section 5.8.1 says that
 > the compressor has to send the list until it gains enough
 > confidence that the decompressor has learnt the mapping. It can be
 > done by sending the list L times in U/O-mode and by receiving an
 > acknowledgement in R-mode. But - as I remember - the compressor
 > will never receive an acknowledgement in O-mode for type 0 and 1
 > packets because only STATIC-NACK or NACK can be sent, according to
 > section 5.4.2.2 (Feedback logic in O-mode).
 >
 > Best regards, Peter
 >
 > _______________________________________________ Rohc mailing list 
[email-masked]

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I
didn't ask for it to be that way)