RE: [rohc] Inconsistent test in Sigcomp Torture Test Document?

On second thoughts, I now see what you mean about the self-reference
issue. It would make it impossible to code the correct value for the
state id, wouldn't it?

Cheers, John

________________________________

	From: John Barber [mailto:john.barber@emccsoft.com] 
	Sent: 28 March 2006 14:07
	To: Vishal Sudan; rohc@ietf.org
	Subject: RE: [rohc] Inconsistent test in Sigcomp Torture Test
Document?

	Hi again Vishal,

	There isn't a problem here, for two reasons:

	1) The creation of state following a STATE-CREATE instruction
*does* obey byte-copying rules. However, the creation of the state item
does not occur at the time the STATE-CREATE instruction is issued - the
request is buffered till end-message time. See
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-0
6.txt Section 4.1.

	2) Even if this were not the case, the STATE-CREATE does not
write to UDVM memory and neither does the instruction in the example
reference the data at state_identifier_b. So I don't see any problem of
self-reference here.

	Cheers, John

________________________________

		From: Vishal Sudan [mailto:vishal@sonimtech.com] 
		Sent: 28 March 2006 13:49
		To: John Barber; rohc@ietf.org
		Subject: RE: [rohc] Inconsistent test in Sigcomp Torture
Test Document?

		> Your concern is that when the STATE-ACCESS instruction
is executed then it will overwrite the 
		> state identifiers which lie just after the
state_address location into which the state item  will  be loaded?

		No. My concern is regarding STATE-CREATE being executed
in the 1st sub-test. 

		What I see are id's different than what are used in the
test code. 

		And since the state_value is 256 bytes long( for state
'b') , and it covers(*) the state_id of the
		state being created ('b') the state_id cannot be known
correctly, right? 
		Sort of a self-referential problem Douglas Hofstadter
would be interested in! 

		Cheers,
		Vishal Sudan

		*Given that STATE-CREATE does not obey byte copying
rules. 

			-----Original Message-----
			From: John Barber
[mailto:john.barber@emccsoft.com]
			Sent: Tuesday, March 28, 2006 3:06 PM
			To: Vishal Sudan; rohc??? 
			Subject: RE: [rohc] Inconsistent test in Sigcomp
Torture Test Document?

			Hi Vishal,

			Your concern is that when the STATE-ACCESS
instruction is executed then it will overwrite the state identifiers
which lie just after the state_address location into which the state
item will be loaded?

			This won't happen, because STATE-ACCESS obeys
the rules for byte copying, and byte_copy_left and byte_copy_right have
been set up to define a four-byte circular buffer at :state_start.
Therefore the state data is written within the confines of this circular
buffer, overwriting itself multiple times in some cases.

			Regards, John

________________________________

				From: Vishal Sudan
[mailto:vishal@sonimtech.com] 
				Sent: 28 March 2006 08:40
				To: rohc??? 
				Subject: [rohc] Inconsistent test in
Sigcomp Torture Test Document?

				Hi all,

				i) For the test in Section 4.2 ( State
memory management ) in Sigcomp Torture test document
				I find state id's generated to be
different than that used in the bytecode provided.

				The document is so well written that for
any other error I'd check my code more than 
				twice for an error on my part but this
testcase generates state id's over its own state id's
				which is surprising.

				The code is , in brief ,

				*   STATE-CREATE ($state_length,
state_start, 0, 6,$state_retention_priority)
				*
				*   ; more code inc. END-MESSAGE etc
				*
				*   :state_start
				*   byte (116, 101, 115, 116)
				*    
				*   :state_identifier_b
				*   byte (249, 1, 14, 239, 86, 123)

				where state 'b' is sized 256 bytes and
the state creation is sure to run over the state id.

				A state sized 0 ( state 'a' ) gets
created properly enough cause it does not use any data bytes.

				I ran the code by putting the id's
before state_start , the id's are still different but the sub-test can
run 
				successfully by changing  them ( in
code) and recompiling the code.

				ii) Another doubt I have is regarding
the state creation and deletion sequence that this test is testing.
				Since states with lesser priorities are
prone to be deleted to made space for greater priorit'ied states(*) 
				the sequence 

				*   Message         Effect 
				*   
				*   0x01               create states:
				*                         (d,768,3)
				*                         (e,1024,4)
				*   
				*   0x02               create states:
				*                         ( c,512,2), -
deleting d
				*                         ( b, 256,1),
				*                         (a,0,0 )

				seems to run counter to (*) at the point
of creation of c ( with priority 2 ) which deletes d ( with priority 3
).

				Any comments would be appreciated.

				Cheers,
				Vishal Sudan

				*From rfc3320 Section 6.2
				              Apart from this special
case, states with the lowest
				     state_retention_priority are always
freed first.