Subject: RE: [rohc] SigComp torture tests

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 22 Apr 2005 17:30:29 +0100

Hi Pekka,

Thanks for the extra corner cases on the state create test.  They are
well worth testing (how long did it take you to find 2 pieces of state
that have the same first 6 bytes of hash? ;-) ).

I think there is also another useful test covered by the way you've
written the bytecode :-)

	7.  Write the bytes of the identifier to the position specified
in the STATE-FREE instruction after the STATE-FREE instruction has been
run (and before END-MESSAGE).

I have a few comments on the message listed as input (I think we might
not need quite so many) but am perfectly happy with the mnemonic and
bytecode.  

> And the test messages:
> 
>    Compressed message:       Number of state items:     UDVM cycles:
>         0x00                          0                      13
This one doesn't do anything - do we need it?

>         0x01                          1                      23
>         0x02                          0                      14
>         0x03                          1                      24
> 
>         0x0400                        Decompression failure   
Is there any reason why this is 0420 rather than 0405 which would test 1
byte below the limit?                    
>         0x0420                        Decompression failure   
Is there any reason why this is 0420 rather than 0415 which would test 1
byte beyond the limit?                    
>         0x0406                        No                     23
						change 'No' to '0'
>         0x09                          1                      34
>         0x0a                          0                      25
>         0x0b                          1                      35
As with the previous version of the test, 0x0a and 0x0b *almost* but
don't quite (if you're being strict about it) cover point 3. 0x0a
recreates an existing piece of state before freeing it; 0x0b creates,
frees and recreates.  However, 0x1e07 and 0x1e14 below both completely
cover point 3 so I'm not sure we need 0x0a and 0x0b.  What do you think?
>         0x1a                          2                      36
>         0x1e06                        2                      46
0x1e06 does pretty much the same as 0x1a (just with 2 attempts to free
the state).  However, it does make a good comparison with 0x1e07 so
maybe we don't need 0x1a?

>         0x1e07                        0                      47
>         0x1e14                        0                      60
>         0x1f14                        1                      70
Similarly, 0x1f14 doesn't really show anything that isn't already shown
so I don't think we need it.  What do you think?

None of these is a big deal, but given that the test can be covered by a
smaller number of test messages I don't see any point in over
complicating it.

Let me know what you think and I'll update the draft accordingly. 
> 
> I took the UDVM cycle count from my notoriously reliable
> debugging output. Caveat emptor.

Our implementation agrees with your cycle counts :-)

Best regards,

Abbie

> 
> --Pekka
> 
> at (64)
> 
> :byte_copy_left                 pad (2)
> :byte_copy_right                pad (2)
> :states                         pad (1)
> :states_lsb                     pad (1)
> :min_len                        pad (1)
> :min_len_lsb                    pad (1)
> 
> :state_identifier		pad (20)
> 
> set (state_length, 10)
> 
> at (128)
> 
> 	INPUT-BYTES (1, states_lsb, !)
> 
> :test_one
> 	LSHIFT ($states, 11)
> 	COMPARE ($states, 32768, test_two, create_state_a2, 
> create_state_a2)
> :create_state_a2
> 	STATE-CREATE (state_length, state_address2, 0, 20, 0)
> 
> :test_two
> 	LSHIFT ($states, 1)
> 	COMPARE ($states, 32768, test_three, create_state_a, 
> create_state_a)
> :create_state_a
> 	STATE-CREATE (state_length, state_address, 0, 20, 0)
> 
> :test_three
> 	LSHIFT ($states, 1)
> 	COMPARE ($states, 32768, test_four, free_state, free_state)
> :free_state
> 	INPUT-BYTES (1, min_len_lsb, !)
> 	STATE-FREE (state_identifier, $min_len)
> 	COPY (identifier1, $min_len, state_identifier)
> 
> :test_four
> 	LSHIFT ($states, 1)
> 	COMPARE ($states, 32768, test_five, free_state2, free_state2)
> :free_state2
> 	STATE-FREE (identifier1, 6)
> 
> :test_five
> 	LSHIFT ($states, 1)
> 	COMPARE ($states, 32768, end, create_state_b, create_state_b)
> :create_state_b
> 	END-MESSAGE (0, 0, state_length, state_address, 0, 20, 0)
> :end
> 	END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
> 
> :identifier1
> 	byte (67, 122, 232, 10, 15, 220, 30, 106, 135, 193, 
> 182, 42, 118, 118, 185, 115, 49, 140, 14, 245)
> 
> 	at (256)
> :state_address
> 	byte (192, 204, 63, 238, 121, 188, 252, 143, 209, 8)
> :state_address2
> 	byte (101, 232, 3, 82, 238, 41, 119, 23, 223, 87)
> 

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

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 02 May 2005 18:49:34 +0300

Hi Abbie,

>that have the same first 6 bytes of hash? ;-) ).

That was surpringly fast. I first hashed a million different
states at 256, then started generating state2 at 266. I estimated
it would take something like two days but I found first collision
after 3 minutes.

>run (and before END-MESSAGE).

OK.

>This one doesn't do anything - do we need it?

Probably not.

>Is there any reason why this is 0420 rather than 0405 which would test 1

No particular reason. Off-by-one might be more useful test.

>Is there any reason why this is 0420 rather than 0415 which would test 1

Ditto.

>cover point 3 so I'm not sure we need 0x0a and 0x0b.  What do you think?

Hm. Probably not needed.

>maybe we don't need 0x1a?

OK.

>so I don't think we need it.  What do you think?

Nope.

>smaller number of test messages I don't see any point in over

I usually let quantity to compensate for the quality when
generating tests, but you have a point here.

>Our implementation agrees with your cycle counts :-)

Excellent. At least, there are bug-compatible implementations... ;)

--Pekka