Subject: [rohc] Interop testing so far

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 25 Aug 2005 15:44:50 +0100

Hi all,

As promised, here is a list of what we understand to be the
functionality of SigComp that could/should be tested.  Following each is
a statement of whether it was tested at SIPit or is tested by the
torture tests (or both).  Where numbers are given, these refer to the
DAP scenario tests used at SIPit that I think test the feature
(<http://sigcomp.srmr.co.uk/cgi-bin/extract_flow.cgi>).

In summary, the things that I think are outstanding are (detailed
version below):

    Creation and use of Minimum retention priority (65535) state
    More than 6 bytes of partial id used in message format 2
    S-bit
    Maybe the I-bit
    Use of the stack (but can this be tested other than by using the
stack 
	instructions? - see Mark's email
<http://www.ietf.org/mail-archive/web/rohc/current/msg03828.html>)
   Failure of state access from message format 2 - again, see Mark's
email

All comments/additions/corrections appreciated.

Best regards,

Abbie

Detail:

1) Resources:
    DMS MUST >= 2K          (implicitly, 1,2,3,... - success)
    CPB MUST >= 16          (implicitly, 1,2,3,... - success)
    SMS MUST >= 0           (implicitly, 1,2,3,... - success)
    If endpoint has more resources it should advertise them 
                            (2 - advertise > 0K SMS - success,
                                           > 2K DMS - success)

2) Transport:    
    Record marking     (14 - success, torture test)

    Mapping 1 app message to 1 sigComp message 
    (MUST for message based and SHOULD for stream based) 
        (implicitly, 1,2,3,... - success)

    VM size according to DMS and transport 
        (torture test)

3) Feedback:
    Feedback should be returned unmodified (2, 3, 18 - success)

4) State handling:
    State cut down to fit SMS tate_memory_size cut down state (torture
test)
    Clashing state hashes (same state, clashing state) (torture test)
    Managing state according to retention priorty and age (11, torture
test)
    
    minimum retention priority state
        (Main use is for shared mode which is informational, however, 
        concept of 65535 state is part of 3320.  It's not tested by the
torture
        tests and wasn't tested at SIPit.  NB. it's more than just
testing 
        adherence to retention priority in that its creation must not
overwrite
        existing non 65535 state) 
        
5) Message formats:    
    Msg format 1 - with uploaded bytecode (implicitly, 1,2,3,... -
success)
    Msg format 2 - with accessing from partial state id 
            (implicitly, 2,3,5,... - success)
    
    Msg with T bit set (feedback length < 128)  (torture test,
implicitly)
    Msg with T bit set (feedback length > 128)  (torture test,
implicitly?)
    
    Accessing state - 6, 9, 12 bytes   (any other than 6 tested?) 

    Failure if message too short (torture tests)
    Failure if 0 or > 1 state items found  
        (no torture test, and failure so not tested at SIPit)
    Failure if min_acc_len wrong 
        (no torture test, and failure so not tested at SIPit)

    Filling in bytes 0-9 in vm (torture test)
    Remaining bytes must be set to zero (implicitly tested?)

    Destination address - (implicitly, torture tests)

6) Running the VM:    
    Registers - behaviour of byt_copy_left, byte_copy_right, 
    input_bit_order, stack_location 
        (implicitly tested by running instructions at SIPit and in 
         torture tests)

    Requesting additional data - INPUT instructions, FHP bits
        (implicitly tested by running instructions at SIPit and in 
         torture tests)

    Stack - tested by instructions 
        (I have no evidence of stack use at SIPit but that doesn't mean
         there wasn't any.  These are tested by the torture tests.)

    Byte copying - tested by instructions 
        (implicitly tested by running instructions at SIPit and in 
         torture tests)

    Operand decoding 
        (implicitly tested by running instructions at SIPit and in 
         torture tests)

    VM cycles checking 
        (implicitly tested by running instructions at SIPit and in 
         torture tests)

    Decomp failure - do we need to test all reasons? 
        (some are tested torture tests)

    Instruction set 
        (implicitly tested by running instructions at SIPit and in 
         torture tests)

    Extras to END-MESSAGE:

        requested feedback:
            Q bit (implicitly tested by running instructions at SIPit
and in 
             torture tests)
    
            S bit (at SIPit nobody understood use of S bit so noone's 
                implementation made use of it => untested)

            I bit (at SIPit implementations could receive and understand
it 
                but most had the state advertisement as part of the
bytecode
                so it wasn't turned off on receipt of the I bit - does
this
                count as interoperating? - there's no requirement on the

                sender to stop advertising, it's a bandwidth saving
option
                but if advertising isn't saving bandwidth, and stopping
would
                cost bandwidth then surely not turning it off is a valid
thing
                to do?)

        advertised params:

            cpb, dms, sms (success - see 1))
            version (torture tests)
            state adverts (2, 5 - success)

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

---

From: tangzhenghua <[email-masked]>
Date: Tue, 30 Aug 2005 08:54:32 +0800

Hi,experts,

I am implementing ROHC protocol and have some problem on the protocol

(1)In section 5.6.5,the limitation on the transition from Reliable to Optimistic mode is the compressor must always run in the FO state during transition.But this limitation is not exist when transition from Optimistic to Reliable mode.So i am confusing with it
(2)Slashes "/" indicate variable length in section 5.2,but as follows
    5.7.7.3.  Initialization of IPv6 Header [IPv6]
    Static part:

      +---+---+---+---+---+---+---+---+
      |  Version = 6  |Flow Label(msb)|   1 octet
      +---+---+---+---+---+---+---+---+
      /        Flow Label (lsb)       /   2 octets
      +---+---+---+---+---+---+---+---+
      |          Next Header          |   1 octet
      +---+---+---+---+---+---+---+---+
      /        Source Address         /   16 octets
      +---+---+---+---+---+---+---+---+
      /      Destination Address      /   16 octets
      +---+---+---+---+---+---+---+---+
     The Source Address and Destination Address are denoted with Slashes "/" ,does it means these fields length are     variable?how can i know the exact length of these two fields?

Regards

Zhenghua

Phone:+86-21-68644808-23504
Mobile:+86-21-28443691
*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************