Subject: RE: [rohc] Sigcomp Implementer's Guide

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Fri, 27 Jun 2003 16:38:39 +0200

Hi,

What happens, if the end of the message buffer was reached without an END-MESSAGE instruction?

RFC 3320 8.6 says: The UDVM stops executing instructions when it encounters an END-MESSAGE instruction or if decompression failure occurs (see Section 8.7 for further details). Section 8.7 however does not mention this situation.
I can see that a dummy END-MESSAGE is present in each torture test case, but there is no test for this special situation.

I dare say this is an uncovered issue. Even though the intention of the authors might be to always have this instruction at the end of the bytecode, my opinion is that in this case the execution should be considered successful, passing the output to the dispatcher. This is a need for compact stateless bytecodes that do not want to use feedback, advertise parameters or save states.

Regardless of the outcome, the result should be a part of the implementor's guide.

Looking forward to your comments!

BR/Zacco

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: 2003. június 23. 12:16
To: [email-masked]'
Subject: RE: [rohc] Sigcomp Implementer's Guide

Hi All,

As I've not received any comments about the proposed additions to the
SigComp Implementer's Guide (see below, posted 17/6) then I assume there are
no objections.  

If anyone has any comments (positive or negative) please send them to the
list by 12pm GMT tomorrow, after which time I will submit the draft.

Cheers,

Abbie

>
>Hi All,
>
>There have been some suggestions for additions to the 
>implementer's guide so here's the proposed text.  Any comments 
>and other additions gratefully received.  I'm planning to 
>resubmit the draft before the -0n deadline so would appreciate 
>comments before the end of this week please - this gives time 
>to make changes and agree them on the list before the deadline.
>
>Clarification that STATE-FREE is compartment specific:
>2nd paragraph added to section 3.2:
>
>"The STATE-FREE instruction can only free state in the compartment
>   that corresponds to the message being decompressed.  Attempting to
>   free state either from another compartment or that is locally
>   available has no effect."
>
>Summary of the outcome of discussion about dynamic DMS and SMS updates:
>
>"8. Dynamic Update of Resources
>
>   Decompressor resources such as SMS and DMS can be 
>dynamically updated
>   at the compressor by use of the SMS and DMS bits in returned
>   parameters feedback (section 9.4.9).  Changing resources dynamically
>   (apart from initial advertisements for each compartment) is not
>   expected to happen very often.
>
>   If additional resources are advertised to a compressor then it is up
>   to the implementation at the compressor whether or not to 
>make use of
>   these resources.  For example, if the decompressor advertises 8k SMS
>   but the compressor only has 4k SMS then the compressor may 
>choose not
>   to use the extra 4k (e.g. in order to monitor state saved at the
>   decompressor).  In this case, there is no synchronisation problem.
>   The compressor must not use more than the most recently advertised
>   resources.  Note that the compressor SMS is unofficial (enables
>   compressor to monitor decompressor state) and is separate from the
>   SMS advertised by the decompressor.
>
>   Reducing the resources has potential synchronisation issues and so
>   should not be done unless absolutely necessary.  If this is the case
>   then the memory should not be reclaimed until the remote 
>endpoint has
>   acknowledged the message sent with the advertisement.  If state must
>   be deleted to accommodate a reduction in SMS then both endpoints
>   should delete it according to the state retention priority (section
>   6.2).  The compressor should use up to the amount of resources most
>   recently advertised."
>
>There was also a suggestion about clarification that state too 
>large for the available SMS in shared mode should be truncated 
>(and the hash computed appropriately).  
>IMHO this is no different from any other state that is too 
>large and is clear in RFC 3320.  Does anyone think this is a 
>useful clarification to include?
>
>Best regards,
>
>Abbie
>
>Abbie Surtees
>Engineer
>Internet Applications and Mobility
>Roke Manor Research Ltd
>Tel:   +44 (0) 1794 833131
>
>
>_______________________________________________
>Rohc mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rohc
>

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

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 2 Jul 2003 14:36:29 +0100

Hi Zacco,

8.7 says decompression failure occurs if the udvm attempts to read from or right to a position beyond the end of the buffer.  I think that reading an instruction is included in this.

Certainly if it is not clear, it was the intention of the authors that instructions going over the end of the buffer should result in decompression failure.

I think that it is clear that if the end of the bytecode is not at the end of the buffer then an END-MESSAGE instruction is needed, otherwise the UDVM will go on and attempt to process the next byte as an instruction.  This may or may not be a valid instruction but if it is, is unlikely to have valid parameters and decompression failure will occur.
e.g. if you remove the END-MESSAGE instruction from the arithmetic torture test, you get decompression failure because the next byte in the buffer is 0.  If you remove it from the sha-1 torture test you get decompression failure because the next byte is 97 which is not a valid instruction.  Both however, have actually decompressed correctly up to that point.

To actually have bytecode finishing at the end of the buffer would be rather hard, as the end of the buffer changes according to the length of the compressed message (assuming UDP).  Consequently to work out where to put code that would finish at the end of the buffer you'd have to read the buffer length from the first two bytes of the buffer, then copy the relevant bytecode.  Surely that takes more bytecode than just including the END-MESSAGE instruction?  (This can be done with one byte if there is nothing to follow it, as in the torture tests, because the parameters can be assumed to be zero.  If there is something following it, then that would run off the end of the buffer anyway!)

Overall, I think that if the UDVM runs off the end of the buffer then there should be decompression failure.  I think this is relatively clear in section 8.7 but could be clarified in the implementer's guide if people really feel that there is a need for it.

Is there such a need?

Best regards,

Abbie

>RFC 3320 8.6 says: The UDVM stops executing instructions when 
>it encounters an END-MESSAGE instruction or if decompression 
>failure occurs (see Section 8.7 for further details). Section 
>8.7 however does not mention this situation.
>I can see that a dummy END-MESSAGE is present in each torture 
>test case, but there is no test for this special situation.
>
>I dare say this is an uncovered issue. Even though the 
>intention of the authors might be to always have this 
>instruction at the end of the bytecode, my opinion is that in 
>this case the execution should be considered successful, 
>passing the output to the dispatcher. This is a need for 
>compact stateless bytecodes that do not want to use feedback, 
>advertise parameters or save states.
>

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Wed, 2 Jul 2003 15:58:45 +0200

Hi,

I agree. I forgot that section, sorry.
Anyway, with a bootstrap bytecode one could upload bytecode anywhere, and then the area of the bootstrap code might be used in the circular buffer that might be a little larger this way. The cost of reading the UMS is out of question here. But, regarding 8.7, it's only theory.

Thanx a lot for the comments!

BR/Zacco

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: 2003. július 2. 15:36
To: Lajos Zaccomer (ET/ETH); [email-masked]'
Subject: RE: [rohc] SigComp Implementer's Guide

Hi Zacco,

Is there such a need?

Best regards,

Abbie

--
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.