Subject: [rohc] Sigcomp User Guide point

From: "John Barber" <[email-masked]>
Date: Tue, 4 Oct 2005 11:59:15 +0100

Hi,

I have a comment about
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-user-guide-0
3.txt.

It is suggested in the document that the following code can be inserted
at after the ":end_of_message" label in order to support CRC checking:

   INPUT-BYTES (2, index, !)
   CRC ($index, 64, state_length, !)

Further down the document, the following code is suggested for provision
of Returned Parameters:

:end_of_message

   LOAD (returned_parameters_location, N)
   INPUT-BYTES (1, adverts_len_lsb, done)
   INPUT-BYTES ($adverts_len, state_ids, done)
   :done

Now, in both these cases, the label :end_of_message will only be called
when an INPUT-BYTES, INPUT-BITS or INPUT-HUFFMAN instruction determines
that the end of the Sigcomp message data has been reached. Therefore,
the attempt to read further data (in the example code above) will surely
fail, resulting in a decompression failure in the first example or
invalid returned parameter data in the second example.

However, it is true that in two (only) of the example decompression
algorithms in the document, :end_of_message can also be reached as a
result of a "COMPARE" UDVM instruction. So in these two cases only, I
can see that the supplied example code might work as intended, if the
effect of the COMPARE instruction is to transfer control to
":end_of_message" before the Sigcomp message data has all been consumed.
If this is the intention, then the document needs to make it clear that
the example code suggested will only work in conjunction with these two
decompression algorithms.

Regards, John

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 4 Oct 2005 15:10:27 +0100

Hi John,

Thanks for pointing this out.  You are quite correct.  There are two
alternative solutions:

1) to point out that these are examples and that the algorithm may need
to be adapted slightly e.g. to have a 'terminate' code/set of bits to
jump to end_of_message

2) to say that the INPUT-BYTES part of the code for crc checking and the
whole of the code for state advertisement could be put before
':initialize_memory' instead of after ':end_of_message'. 

I'd go for 2) because it's a simple change for the draft.  What do you
think?

One thing that I've also noticed is that in section 5.2, it should
probably be add that where the static dictionary is put in vm memory may
depend on the algorithm in use.  

The draft has gone already through WGLC.  Can these changes be made
directly and a new version issued?

Best regards,

Abbie

P.S. It should be noted, that the bytecodes and algorithms provided in
this user guide are all examples and an implementer can make use
of/alter/not use them as (s)he sees fit.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of John Barber
> Sent: Tuesday, October 04, 2005 11:59 AM
> To: [email-masked]
> Subject: [rohc] Sigcomp User Guide point
> 
> 
> Hi,
> 
> I have a comment about

---

From: "John Barber" <[email-masked]>
Date: Tue, 4 Oct 2005 15:17:47 +0100

Hi Abbie,

Thanks for you quick response. And thanks for confirming that it was
indeed an error - now I know I'm not going mad after all ;-)

I'm inclined to prefer your correction (1) to the document. Solution (2)
would imply that the CRC bytes need to be output by the compressor
before the message which they refer to. This could cause problems
implementing the compressor, particularly if it is to operate in
"streaming" mode.

Best regards, John 

> From: Surtees, Abigail [mailto:[email-masked]] 
> Sent: 04 October 2005 15:10
> To: John Barber; [email-masked]
> Cc: Lars-Erik Jonsson (LU/EAB); Carsten Bormann
> Subject: RE: [rohc] Sigcomp User Guide point
> 
> Hi John,
> 
> Thanks for pointing this out.  You are quite correct.  There 
> are two alternative solutions:
> 
> 1) to point out that these are examples and that the 
> algorithm may need to be adapted slightly e.g. to have a 
> 'terminate' code/set of bits to jump to end_of_message
> 
> 2) to say that the INPUT-BYTES part of the code for crc 
> checking and the whole of the code for state advertisement 
> could be put before ':initialize_memory' instead of after 
> ':end_of_message'. 
> 
> I'd go for 2) because it's a simple change for the draft.  
> What do you think?
> 
> One thing that I've also noticed is that in section 5.2, it 
> should probably be add that where the static dictionary is 
> put in vm memory may depend on the algorithm in use.  
> 
> The draft has gone already through WGLC.  Can these changes 
> be made directly and a new version issued?
> 
> Best regards,
> 
> Abbie
> 
> P.S. It should be noted, that the bytecodes and algorithms 
> provided in this user guide are all examples and an 
> implementer can make use of/alter/not use them as (s)he sees fit.
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of John Barber
> > It is suggested in the document that the following code can be 
> > inserted at after the ":end_of_message" label in order to 
> support CRC 
> > checking:
> > 
> > Further down the document, the following code is suggested for 
> > provision of Returned Parameters:
> > 
> > :end_of_message
> > 
> > Now, in both these cases, the label :end_of_message will only be 
> > called when an INPUT-BYTES, INPUT-BITS or INPUT-HUFFMAN instruction 
> > determines that the end of the Sigcomp message data has 
> been reached. 
> > Therefore, the attempt to read further data (in the example code 
> > above) will surely fail, resulting in a decompression 
> failure in the 
> > first example or invalid returned parameter data in the second 
> > example.
> > 
> > If this is the intention, then the document needs to make it clear 
> > that the example code suggested will only work in conjunction with 
> > these two decompression algorithms.
> > 
> > Regards, John
> >

---

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 14 Oct 2005 09:12:12 +0100

Hi John, all,

> implementing the compressor, particularly if it is to operate in

The bytes would need to be in the message before the message they refer
to.  When they are generated is an implementation choice (though
obviously the availability of the bytes over which to crc has to reflect
what will happen at the decompressor).  I don't think this is a big
issue, but it seems solution (2) could still lead to confusion, so I'm
quite happy to go with solution (1).

In which case, I propose the following changes:

Section 2, last paragraph.
"Any or all of the above mechanisms can be implemented in conjunction
   with the chosen compression algorithm.  A subroutine of UDVM bytecode
   is provided for each of the mechanisms; these subroutines can be
   added to the bytecode for one of the basic compression algorithms."

->

"Any or all of the above mechanisms can be implemented in conjunction
   with the chosen compression algorithm.  An example subroutine of UDVM
bytecode
   is provided for each of the mechanisms; these subroutines can be
   added to the bytecode for one of the basic compression algorithms.
(NB. The subroutine or the basic algorithm may require minor
modification to ensure they work together correctly.)"

Section 5, insert new paragraph between paragraphs 1 & 2:

"Example assembly code is provided for these mechanisms.  Depending on
the mechanism and basic algorithm in use, the assembly code for either
the mechanism or the basic algorithm may require modification (e.g. if
the algorithm uses 'no more input' to jump to end_of_message, following
end_of_message with an input instruction for CRC will not work).  In any
case, these are examples and there may be alternative ways to make use
of the mechanisms."

> > put in vm memory may depend on the algorithm in use.  

Proposal - add the sentence "The parameters of STATE-ACCESS instruction
will depend on the algorithm in use." after the STATE-ACCESS
instruction.

Any comments?

Best regards,

Abbie

---

From: "John Barber" <[email-masked]>
Date: Fri, 14 Oct 2005 14:10:04 +0100

Hi Abbie,

Just to confirm that your proposed changes succeed in clarifying the
points in the document that had confused me.

Best regards, John 

> From: Surtees, Abigail [mailto:[email-masked]] 
> Sent: 14 October 2005 09:12
> The bytes would need to be in the message before the message 
> they refer to.  When they are generated is an implementation 
> choice (though obviously the availability of the bytes over 
> which to crc has to reflect what will happen at the 
> decompressor).  I don't think this is a big issue, but it 
> seems solution (2) could still lead to confusion, so I'm 
>    with the chosen compression algorithm.  An example 
> subroutine of UDVM bytecode
> "Example assembly code is provided for these mechanisms.  
> Depending on the mechanism and basic algorithm in use, the 
> assembly code for either the mechanism or the basic algorithm 
> may require modification (e.g. if the algorithm uses 'no more 
> input' to jump to end_of_message, following end_of_message 
> with an input instruction for CRC will not work).  In any 
> case, these are examples and there may be alternative ways to 
> make use of the mechanisms."
> 
> > > probably be add that where the static dictionary is put 
> in vm memory 
> > > may depend on the algorithm in use.
> > > 
> 
> Proposal - add the sentence "The parameters of STATE-ACCESS 
> instruction will depend on the algorithm in use." after the 
> STATE-ACCESS instruction.
> 
> Any comments?
> 
> Best regards,
> 
> Abbie