Subject: RE: [rohc] WG Last call comments on SigComp user guide and torture tests

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 17 Oct 2005 16:36:35 +0100

Hi Adam,

You're right, the useful values test should work on both a version 1
UDVM and a version 2 UDVM.  How about, rather than having two different
versions of the bytecode (and a given UDVM only being able to run one of
them), changing the bytecode so that the version number is read in from
the message rather than being hard coded?  That way, the bytecode itself
is not specific to either UDVM.  What do you think? 

Best regards,

Abbie 

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, October 13, 2005 10:41 PM
> To: Surtees, Abigail
> Cc: [email-masked]
> Subject: Re: [rohc] WG Last call comments on SigComp user 
> guide and torture tests
> 
> 
> Sorry to jump in at the very last moment, but I just remembered 
> something that may be worth addressing...
> 
> If you're running the torture tests against an implementation 
> that uses 
> RFC4077, the "Useful Values" tests will fail. They're specifically 
> checking for a UDVM version of 0x0001 -- but RFC4077 implementations 
> will set this value to 0x0002.
> 
> Probably the easiest thing to do is publish two versions of 
> the bytecodes.
> 
> Note that this also changes the hash value for the state. So, for 
> example, if you simply modify the expected version like so:
> 
>    0xf805 a10e 8620 0ea0 4221 1742 02f8 06f8 1743 00f2 060c 1744 00ec
>    0x3fec 1744 a3c0 e607 e61c 01a0 479f df06 2340 0723 0112 2001 631c
>    0x01a0 499f cf0e a044 4306 2203 0822 0806 22a3 e808 2241 0622 6407
>    0x22a3 d612 2062 2023 0000 a3c0 8687 06
> 
> ...then your subsequent messages (for the second, third, and fourth 
> runs) would look like this:
> 
>    0xf946 8475 55D9 2D
> 
> /a
> 
> Surtees, Abigail wrote:
> 
> >Hi All,
> >
> >Here are my WGLC comments for the user guide and torture 
> test drafts (other than those discussed with John last week).
> >
> >User guide:
> >
> >Page 34, section 5.3 "Whilst the acknowledgement scheme of 
> Section 5.1 is designed to
> >   ensure that SigComp does not propagate errors introduced by the
> >   underlying transport layer, in some cases it may be 
> useful to add an
> >   extra CRC check over the UDVM memory.  For example, if 
> the transport
> >   layer fails to discard a damaged SigComp message then a 
> CRC check can
> >   ensure that the corresponding decompressed message is not 
> forwarded
> >   to the application."
> >
> >I found the first sentence of this paragraph confusing and 
> think it could be worded more clearly.
> >
> >Proposed text: "The acknowledgement scheme of Section 5.1 is 
> designed to indicate the successful decompression of a 
> message.  However, it does not guarantee that the 
> decompressed message is identical to the original message, 
> since decompression of a corrupted message could succeed but 
> with some characters being incorrect. This could lead to an 
> incorrect message being passed to the application or 
> unexpected contents of state to be stored.  In order to 
> prevent this happening a CRC check could be used."
> >
> >What do you think?
> >
> >Minor nits:
> >Page 3, Section 1 paragraph 3: 'This document offers' -> 
> 'This document gives examples of'
> >Page 8, last but 1 paragraph: missing ',' after 'then'
> >Page 9, last but 1 paragraph: extra 's' in 'usually'
> >Page 17, first paragraph: extra blank line
> >Page 21, extra word DEFLATE by reference (confusing)
> >Page 35, list of parameters: 'state_memory_size>' - extra >
> >Page 37, paragraph 2: extra 'Section'
> >Refs - re-order to reflect order in which they are referred 
> to and remove call flow reference (currently [1]) as it's not used.
> >
> >Torture tests:
> >
> >The SHA-1 test changed in the last revision to have a SHA-1 
> over 16384 instead of 65535 bytes.  However though the 
> comment in the code changed, I appear to have missed the 
> value in the instruction itself (which also affects the 
> bytecode in the appendix).
> >
> >So:
> >"  ; Perform SHA-1 over a  16384 bytes in a 1 byte buffer
> >   SHA-1 (test_three, 65535, hash_value)
> >   OUTPUT (hash_value, 20)"
> >
> >Should say:
> >"  ; Perform SHA-1 over a  16384 bytes in a 1 byte buffer
> >   SHA-1 (test_three, 16384, hash_value)
> >   OUTPUT (hash_value, 20)
> >
> >Output line "   0xe1d0 a18d 43d3 a689 af08 8e15 6bd0 434a 
> a0c8 31fc" shouldn't be there (there are only 4 SHA-1s output).
> >
> >The second line of the translated code in the appendix should not be 
> >" 0xfe0e a042 a0ff 0da0 feff a044 22a0 4414 0e86 a0ff 0ea0 42a1 070d"
> >But should be
> >" 0xfe0e a042 a0ff 0da0 fe8e a044 22a0 4414 0e86 a0ff 0ea0 42a1 070d"
> >
> >Best regards,
> >
> >Abbie
> >
> >
> >
> >Abbie Surtees
> >Senior Engineer
> >Roke Manor Research Ltd
> >Old Salisbury Lane
> >Romsey, SO51 0ZN
> >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

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Oct 2005 11:11:21 -0500

That seems to solve the problem in a more flexible fashion. Sounds good 
to me.

/a