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

From: "Vishal Sudan" <[email-masked]>
Date: Tue, 28 Mar 2006 13:10:20 +0530

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.

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

---

From: "John Barber" <[email-masked]>
Date: Tue, 28 Mar 2006 10:36:29 +0100

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:[email-masked]] 
	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:
	 
	seems to run counter to (*) at the point of creation of c ( with
priority 2 ) which deletes d ( with priority 3 ).

	Cheers,
	Vishal Sudan

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

---

From: "John Barber" <[email-masked]>
Date: Tue, 28 Mar 2006 10:48:30 +0100

Hi again Vishal,
 
On you second query (doubt regarding state creation and deletion
sequence), the TORTURE test is correct. The SIGCOMP RFC section 6.2
which you quote is talking about which item of existing state should be
deleted to make space for a new item. The priority of the new item
itself is irrelevant at this point, i.e. a new item of low-priority
state can displace an existing item of higher-priority state.
Prioirities are used to decide *which* existing item of state should be
deleted first.
 
Regards, John

	From: John Barber [mailto:[email-masked]] 
	Sent: 28 March 2006 10:36
	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?

	Regards, John

		From: Vishal Sudan [mailto:[email-masked]] 
		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 ,

		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:

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

		Cheers,
		Vishal Sudan

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

---

From: "Vishal Sudan" <[email-masked]>
Date: Tue, 28 Mar 2006 18:18:55 +0530

> 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:[email-masked]]
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:[email-masked]] 
Sent: 28 March 2006 08:40
To: rohc??? 
Subject: [rohc] Inconsistent test in Sigcomp Torture Test Document?

Hi all,

 
The code is , in brief ,

 

 
*   Message         Effect 
*   
*   0x01               create states:
*                         (d,768,3)
*                         (e,1024,4)
*   
*   0x02               create states:

 
Cheers,
Vishal Sudan

---

From: "West, Mark" <[email-masked]>
Date: Tue, 28 Mar 2006 13:59:20 +0100

Vishal,

STATE-CREATE does obey byte-copying rules, although this is not categorically stated in RFC 3320.  However, Section 4.1 of the implementers' guide contains:

"When state is created by the state-handler (whether the instruction
   was from END-MESSAGE or STATE-CREATE), the byte copying rules of
   section 8.4 apply."

Cheers,

Mark.

-----Original Message-----
From: Vishal Sudan [mailto:[email-masked]]
Sent: Tue 3/28/2006 1:48 PM
To: John Barber; [email-masked]
Subject: RE: [rohc] Inconsistent test in Sigcomp Torture Test Document?

 

Cheers,
Vishal Sudan

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

Hi Vishal,

 
Regards, John

  _____  

Hi all,

 
The code is , in brief ,

 

 
*   Message         Effect 
*   
*   0x01               create states:
*                         (d,768,3)
*                         (e,1024,4)
*   
*   0x02               create states:

 
Cheers,
Vishal Sudan

---

From: "John Barber" <[email-masked]>
Date: Tue, 28 Mar 2006 14:06:35 +0100

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:[email-masked]] 
	Sent: 28 March 2006 13:49
	To: John Barber; [email-masked]
	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

		-----Original Message-----
		From: John Barber [mailto:[email-masked]]
		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

			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 ,

			 
			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 ).

			Cheers,
			Vishal Sudan

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

---

From: "Vishal Sudan" <[email-masked]>
Date: Tue, 28 Mar 2006 18:44:13 +0530

Hi, 
 
Thanks for pointing it out. Haven't been doing it that way.
So, unsurprisingly, the number of bugs I have found in this doc remains at 0.
 
Thanks and Cheers,
Vishal Sudan

[Vishal Sudan]  -----Original Message-----
From: West, Mark [mailto:[email-masked]]
Sent: Tuesday, March 28, 2006 6:29 PM
To: Vishal Sudan; John Barber; [email-masked]
Subject: RE: [rohc] Inconsistent test in Sigcomp Torture Test Document?

Vishal,

Cheers,

Mark.

-----Original Message-----
From: Vishal Sudan [ mailto:[email-masked]]
Sent: Tue 3/28/2006 1:48 PM
To: John Barber; [email-masked]
Subject: RE: [rohc] Inconsistent test in Sigcomp Torture Test Document?

Cheers,
Vishal Sudan

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

Hi Vishal,

Regards, John

  _____ 

From: Vishal Sudan [ mailto:[email-masked]]
Sent: 28 March 2006 08:40
To: rohc???
Subject: [rohc] Inconsistent test in Sigcomp Torture Test Document?

Hi all,

The code is , in brief ,

*   Message         Effect
*  
*   0x01               create states:
*                         (d,768,3)
*                         (e,1024,4)
*  
*   0x02               create states:

Cheers,
Vishal Sudan

---

From: "John Barber" <[email-masked]>
Date: Tue, 28 Mar 2006 14:16:28 +0100

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:[email-masked]] 
	Sent: 28 March 2006 14:07
	To: Vishal Sudan; [email-masked]
	Subject: RE: [rohc] Inconsistent test in Sigcomp Torture Test
Document?

	Hi again Vishal,

	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

		
		 
		> Your concern is that when the STATE-ACCESS instruction
is executed then it will overwrite the 
		> state identifiers which lie just after the
		 
		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:[email-masked]]
			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:[email-masked]] 
				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
).

				Cheers,
				Vishal Sudan

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

---

From: "Vishal Sudan" <[email-masked]>
Date: Tue, 28 Mar 2006 18:54:14 +0530

Hi John,
 
Thanks for pointing out the that STATE-CREATE obeys byte-copying rules. Did'nt know about that.
 
> It would make it impossible to code the correct value for the state id, wouldn't it?
Yes , as it was for me till this morning !
 
Thanks and Cheers,
Vishal Sudan

[Vishal Sudan]  -----Original Message-----
From: John Barber [mailto:[email-masked]]
Sent: Tuesday, March 28, 2006 6:46 PM
To: John Barber; Vishal Sudan; [email-masked]
Subject: 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

  _____  

Hi again Vishal,

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-06.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

  _____  

 

 
 
Cheers,
Vishal Sudan

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

Hi Vishal,

 
Regards, John

  _____  

Hi all,

 
The code is , in brief ,

 

 
*   Message         Effect 
*   
*   0x01               create states:
*                         (d,768,3)
*                         (e,1024,4)
*   
*   0x02               create states:

 
Cheers,
Vishal Sudan