Subject: RE: [rohc] WG last-call for SigComp User Guide and Torture Tests

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 11 Aug 2005 16:35:40 +0100

Hi All,

It's been pointed out to me that the torture test draft doesn't say what
cpb, dms and sms are required for the tests.  I suggest this should be
added.  

With the exception of the SHA-1 test, they all run in 16cpb, 2k dms and
2k sms (where it's used).  
I suggest that the SHA-1 test is changed to work in 16cpb (e.g. by
changing the SHA-1 over 65535 bytes to be over 16384 bytes) so that all
the tests are consistent.  Also, the second statement of what the SHA-1
test tests doesn't make sense and should probably be removed. 

If a test that uses cpb > 16 is wanted, one way to achieve it could be
to add the expected termination point when cpb = 32 to the infinite loop
test (section 3.2).

What does anyone think?

Best regards,

Abbie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Lars-Erik Jonsson (LU/EAB)
> Sent: Thursday, August 04, 2005 2:34 PM
> To: [email-masked]
> Subject: [rohc] WG last-call for SigComp User Guide and Torture Tests
> 
> 
> ROHCers,
> 
> We have been working on several informational documents to help
> implementers of SigComp. Since some of these have now been stable
> for a long time, and both authors and chairs believe these are
> ready, we are now last-calling the following documents:
> 
>             draft-ietf-rohc-sigcomp-torture-tests-01.txt
>                  (for publication as Informational)
> 
>             draft-ietf-rohc-sigcomp-user-guide-02.txt
>                  (for publication as Informational)
> 
> This will be the usual two-week WG last-call as suggested in RFC2418,
> officially starting on Fri, 2005-08-05, 18:00 UTC. Please direct
> last-call comments to the ROHC mailing list [email-masked] before Fri,
> 2005-08-19, 18:00 UTC.
> 
> Rgds,
> /L-E
> 
> 
> _______________________________________________
> 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: "Surtees, Abigail" <[email-masked]>
Date: Mon, 22 Aug 2005 16:27:38 +0100

Hi Cristian, Pekka,

Yes, you are right that udvm memory size is 8192 which requires DMS or
16K and that 8K of state is created.  (I had missed that :-( )

The figures I quoted are the figures in which it can run if you don't
actually allow the state creation - not all of the buffer is used so
during execution you never get to byte_copy_right (8192).  However, if
you want to successfully create the state then you do need 16K DMS and
8K SMS and the statement should reflect this.

NB it is up to the 'application' to allow or disallow state creation and
the state creation may or may not succeed.  TCP (or other 'reliable'
transport protocols) does not guarantee that state was created, only
that the SigComp messages arrive and that they arrive in order.
Consequently, I don't think the lack of request for feedback implies
TCP.  There is no feedback requested for simplicity - the example
bytecode for requesting feedback is presented in a later section of the
draft (5.1).

Actually, it states in section 5.1:

"   The simplest method for acknowledging a SigComp state item is to
   employ a reliable transport layer such as TCP or SCTP.
   Alternatively, over an unreliable transport such as UDP the SigComp
   feedback mechanism can be used to acknowledge that a state item has
   been successfully created at the receiving endpoint.
	
    As explained in SigComp RFC-3320 [4], in order to invoke the
feedback
   mechanism the following fields must be reserved in the UDVM memory:"

I think the first paragraph is a slightly misleading statement for the
reason given above.  I suggest it should be changed to:

"SigComp RFC-3320 [4] defines a feedback mechanism to allow the
compressor to request feedback from the decompressor, to give the
compressor indication that a message has been received, correctly
decompressed and state storage attempted.  (Note, this mechanism cannot
convey the success or failure of individual state creation requests.)
In order to invoke the feedback mechanism the following fields must be
reserved in the UDVM memory:"

What do you think?

Best regards,

Abbie
 
> Cristian CONSTANTIN <[email-masked]> writes:
> >> Yes, you're right, the minimum values needed should be stated.  I
> >> believe they all run in 16cpb and there is no state 
> storage so 0 SMS is
> >> ok.
> 
> >cristian: what exactly do you mean by "state storage"? I 
> have seen that all 
> >these decompressors make state create requests in their 
> END-MESSAGE; an example 
> >from "4.1.1  Simplified LZ77":
> 
> >END-MESSAGE (requested_feedback_location,
> >   returned_parameters_location, state_length, 64,
> >   decompress_sigcomp_message, 6, 0)
> 
> To me it looks like all the basic algorithms in section 4 require
> TCP (no feedback), 16K of DMS (because udvm memory size is 8192)
> and 8K of SMS (as the size of state item created is 8192 - 64).
> 
> --Pekka
> 
> >> > Behalf Of Cristian CONSTANTIN
> >> > Sent: Friday, August 19, 2005 1:21 PM
> >> > To: Lars-Erik Jonsson (LU/EAB)
> >> > Cc: [email-masked]
> >> > Subject: Re: [rohc] WG last-call for SigComp User Guide and 
> >> > Torture Tests
> 
> 
> >> > On Thu, Aug 04, 2005 at 03:33:46PM +0200, Lars-Erik Jonsson 
> >> > (LU/EAB) wrote:
> >> > > ROHCers,
> 
> >> > cristian: one single comment related to this draft; namely, 
> >> > shouldn't a
> >> > minimum acceptable value of the cpb, dms, sms parameters be 
> >> > recommended for 
> >> > the udvm code specified in "4.  Compression algorithms" ?
> 
> >> > bye now!
> >> > cristian
> >> > -- 
> >> >  _          | There are many people who use UNIX or Linux  
> >> > (_'_        | who IMHO do not understand UNIX.
> >> >   (_'rist   |              --David Korn  
> >> > GPG public key at wwwkeys.de.pgp.net
>