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.