Subject: [rohc] SigComp Interop

From: "Price, Richard" <[email-masked]>
Date: Mon, 27 Jan 2003 17:33:11 -0000

Hi,

Attached is a first attempt at a test suite for the SigComp Interop.
Comments welcome!

Regards,

Richard

P.S. I also have a few answers to some issues raised in the original
proposal from Zacco:

> 1.2. Check if compressor and decompressor uses the same or separate
> state memory. (not specified in standard)

This should be covered by the following text from Section 6.2 of SigComp:

   Note that locally available state items (as described in Section
   3.3.3) need not be mapped to any particular compartment.  However, if
   they are created on a per-compartment basis, then they must not
   interfere with the state created at the request of the remote
   endpoint.  The special state_retention_priority of 65535 is reserved
   for locally available state items to ensure that this is the case.

So a compressor can create its own state in the state memory reserved for
the decompressor, but it must use the special state_retention_priority
of 65535. This makes sure that if the state memory runs out then the
state created by the compressor is discarded first (otherwise messages
might not decompress correctly).

> 2.1. Using shared state
> Calculation of shared state ID (not exactly specified in the
> draft, what to test?)

The contents of the shared state (and consequently the shared state ID)
should be exactly specified by RFC 3321. What the interop should test is
that Endpoint 1 can save a shared state and announce the corresponding
state ID to Endpoint 2, which then makes use of the state to improve the
overall compression ratio. The exact message format used to achieve this
is an implementation decision, but if any implementations can test the
example format given in RFC 3321 then that would be a bonus.

> 2.3. Using local endpoint initiated explicit acknowledgement
> What state ID is handled as an acked_state_id? (not specified in draft)

The acked_state_id can carry the ID of any state previously created by
the decompressor (in other words it's an alternative to using the
requested and returned SigComp feedback to acknowledge states).

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Tue, 28 Jan 2003 08:51:26 +0100

Hi,

Thank you for the answers Richard, but it is as I feared, I need further explanations (see below):

-----Original Message-----
From: Price, Richard [mailto:[email-masked]]
Sent: Monday, January 27, 2003 6:33 PM
To: [email-masked]'
Subject: [rohc] SigComp Interop

Hi,

Regards,

Richard

[L.Z.] This is a serious disadvantage, because the compressor may not be sure how much memory is still available in the remote endpoint as its compressor using shared and/or dynamic compression might save states, which the local endpoint's compressor will not know about. This makes tracking the memory usage impossible, and thus the compressor may not be sure if the message can be decompressed successfully.

[L.Z.] In RFC 3221, the minimum access length with that the shared state ID should be calculated is not specified.

[L.Z.] It's easy to say any, and it's also easy to implement. But in this case the remote endpoint may think differently of how to interpret an acked state ID. Let us suppose a bytecode saves two states, one for the bytecode and one for the part of the uncompressed message that remained in the UDVM memory. Which state ID is sent back as an acked state ID?

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

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 28 Jan 2003 14:17:59 -0000

> [L.Z.] This is a serious disadvantage, because the compressor 
> may not be sure how much memory is still available in the 
> remote endpoint as its compressor using shared and/or dynamic 
> compression might save states, which the local endpoint's 
> compressor will not know about. This makes tracking the 
> memory usage impossible, and thus the compressor may not be 
> sure if the message can be decompressed successfully.

Hi Zacco,

I think that the confusion with this issue is that what you call the
"local endpoint", I'm calling the "remote endpoint" and vice versa.
On my part I'm using the term "local endpoint" to mean the endpoint
that is actually saving the state. The "remote endpoint" is the one that
asks for new state to be created, and makes use of the state to improve
the overall compression ratio.

In order to ensure successful decompression, the remote endpoint must
always know how much state memory is available at the local endpoint (in
case it wants to ask for more state to be created). Consequently, any
states created by the local endpoint *must not* prevent the remote
endpoint from tracking how much state memory is left - in particular
a state creation request by the remote endpoint must not fail because
the local endpoint has filled up the state memory with its own state
(e.g. shared state) that the remote endpoint doesn't know about.

The solution is to give the state created at the request of the remote
endpoint a higher priority than any state created locally. This ensures
that if the state memory becomes full, any state created by the local
endpoint will be pushed out invisibly without interfering with the
remote endpoint's view of how much state memory is left.

> [L.Z.] In RFC 3221, the minimum access length with that the 
> shared state ID should be calculated is not specified.

The minimum access length is up to the implementer, depending on how much
protection is needed against malicious users attempting to access the
shared state. If security isn't a problem then use the smallest possible
value (namely 6 bytes).

> [L.Z.] It's easy to say any, and it's also easy to implement. 
> But in this case the remote endpoint may think differently of 
> how to interpret an acked state ID.

From the perspective of the remote endpoint it makes no difference what
is carried in the acked state ID. The endpoint just keeps a list of
the states it would like to use for compression (including the states it
previously created, shared states, well-known compression algorithms
etc.). If the state ID for one of these states is announced then it
marks the state as "available" and uses it to compress messages.

> Let us suppose a bytecode saves two states, one for the bytecode and
> one for the part of the uncompressed message that remained in the UDVM
> memory. Which state ID is sent back as an acked state ID?

That's up to the local endpoint - whichever it thinks will be more
useful for the remote endpoint to receive. To be on the safe side it
could even send both (this means that the example header given in RFC
3321 would need to be rewritten, but this is no problem because the
precise format of the header is also up to the local endpoint).

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 28 Jan 2003 14:17:59 -0000

Hi Zacco,

Regards,

Richard