Subject: [rohc] RE: SigComp Recovery - long

From: [email-masked]
Date: Wed, 30 Oct 2002 15:45:14 +0100

Hi,

Some comments and a summary on the issue.

Dynamicsoft:

The solution is rather straightforward, but it introduces some implementation problems. Here is the list and the possible solutions:

1. Section 2.1 - Memory problems

	Problem:
Endpoints have to store SHA-1 hash and - in case of reliable transport - the uncompressed version of ALL messages sent out. This is hardly acceptable from the memory point of view on both sides. Moreover the draft does not define when to release this data, since we have no ACK.

	Possible solution:
Allow endpoints to handle just a set of error codes (which are not message specific). Thus it does not have to store anything, but is still able to react to STATE_NOT_FOUND for example. The other errors could trigger some default actions (like RESET). However, we lose the retransmission possibilities in case of TCP this way. 

	Needed action:
Change two musts to should in section 2.1 

2. Problem with damaged messages: Damaged messages will be likely to trigger decompression failure, but the SHA-1 hash will not match the one stored in the other end. However with transport layer CRC this can be kept to a minimal level.

3. Section 2.2 - Response address

	Problem:
NACK will be sent to the port (or connection) the message came from, where no one may be listening.

	Possible solution:
In 3GPP for example the user is identified by IPsec and the listening ports are also known.

	Needed actions:
Include something like "if the listening address/port is known by the application, NACK messages may be sent to that address instead".

4: Piggybacking

	Problem:
Piggybacking is not possible because of the message format.

	Possible solution:
Not easy. NACK could be indicated elsewhere then code length, such as a "magic cookie" in the returned feedback item. The version field then could be removed (or included elsewhere), and code length allowed to be non-zero and. If there is a returned feedback field already (from a previous message for example) it could be attached to the NACK feedback or ignored.

5. As with all standalone messages: NACK has to "bypass" authorization and get the compartment identifier without a valid uncompressed message whatsoever.

Nokia:

The draft has obviously two parts. Based on IETF discussion one of them should be removed.

3GPP has once rejected the one-bit RESET, because it used a reserved bit that could interfere with future releases. If IETF could reserve bit 4 for RESET this should not be a problem anymore. Then we would have a quick solution that is still nicer than reducing state memory size to 0.

With the other solution we could live with the lone RESET signal for now and define more later or define a reasonable set of errors (this would be better).

Error codes:

As I see the current view is either to

1. define a very limited number of codes and skip the others because they are just for debug
2. define a full set with plenty of error codes

What I am missing here is the supposed actions. IMHO we could define error classes and the possible actions for that to make life simpler. A possible classification could be:

1. State problems: missing state, minimum_access_length too large, more than one match for a prefix
2. Syntactic and semantic problems: errors in the SigComp message, instruction-specific errors, unknown instructions, etc. (including more than four state creation attempts, which does not belong to class 1)
3. Manual decompression failure: decompression-failure instruction encountered
4. Resource problems: CPU limit exceeded, message is larger than decompression_memory_size, out-of-UDVM memory address

Possible reactions: 

1: Do not use any state that was problematic (or try it with a longer prefix)
2: Write a bug-free code in the first place :-). Send the message by other means (different algorithm, static compression, uncompressed, etc.)
3: The compressor should know what happened and what actions should be taken
4: Try to compress the message by other means or send it uncompressed

1-4: If it needs too much logic from the compressor, just reset the compartment in every case

Simpler implementations could use only the fact of error, medium implementation could use the error classes, and full implementations could make full use of error codes.

Politics:

3GPP will have a meeting 11th-15th November in Bangkok, where this issue will be discussed or even closed. It would be good if IETF could define at least a common "point-of-view" by that time as a guideline, so we do not end up with incompatible solutions in the end.

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2002 11:05:49 -0600

> Dynamicsoft:

No, not dynamicsoft. Adam Roach. In the IETF, we participate as
individuals. If you try to act as a corporation instead of an
individual, the politics tend to get a bit too thick. This can
sometimes result in strained attempts to find technical problems
where none exist; these attempts tend to inhibit rather than foster
progress.

> Endpoints have to store SHA-1 hash and - in case of reliable 
> transport - the uncompressed version of ALL messages sent 
> out. This is hardly acceptable from the memory point of view 
> on both sides. Moreover the draft does not define when to 
> release this data, since we have no ACK.

You can discard such information on a LRU basis, if need be.
The storage of uncompressed versions of messages is no different
than the requirements placed on an application by an unreliable
transport. Such information needs to be stored only until an
application-level response to the message is received, and can
be timed out if the application level protocol expects no such
response.

I've already implemented this scheme in an extremely constrained
environment with no problems.

> 2. Problem with damaged messages: Damaged messages will be 
> likely to trigger decompression failure, but the SHA-1 hash 
> will not match the one stored in the other end. However with 
> transport layer CRC this can be kept to a minimal level.

Red Herring. Any transport that has been proposed for SigComp
performs packet-level checksumming.

Futher, any reliable transport will ensure uncorrupted delivery.
Any unreliable transport will provide application-level 
reliability, and recovery can occur on the next message, even
if a corrupted packet manages to slip by.

This is a complete non-issue.

> NACK will be sent to the port (or connection) the message 
> came from, where no one may be listening.

No, if you implement NACK, you listen there. It's specified.

> listening ports are also known.

That's a connection-oriented setup. If you read my proposal
carefully, responding to the source port is only used for
*connectionless* setups.

> 	Needed actions:
> Include something like "if the listening address/port is 
> known by the application, NACK messages may be sent to that 
> address instead".

If other people think this is useful, I can add it -- however,
it would appear to add implementation complexity: how do you
know whether the *other* side is going to use this "MAY"? You'll
have to listen for NACKs in two places instead of one! Hardly
an improvement.

> Piggybacking is not possible because of the message format.

Piggybacking is also not possible because the NACK is sent
immediately upon receipt of a bad message. Piggybacking was
not considered a requirement. Do you think it's important?
We can figure out a way to add it, but I'd like to at least
have consensus within the working group that it's something
that's generally wanted first.

> 5. As with all standalone messages: NACK has to "bypass" 
> authorization and get the compartment identifier without a 
> valid uncompressed message whatsoever.

If the group thinks it necessary, we can add an authentication
mechanism to NACK messages, as long as we're willing to
accept the resultant increase in message size and the complexity
of key distribution. I'll be happy to go down that path if it's
what the working group wants.

Personally, I don't think it's too terribly necessary. NACK
messages can't store state, and they don't invoke the UDVM --
so an attempt to exhaust resources isn't possible. The worst
that can be acheived is that a concerted stream of NACKs
aimed at one node might result in poorer-than-expected
compression ratios. Since this doesn't seem like a very
damaging attack, and because the attacker has to expend
considerable resources to perform it (i.e. constantly sniffing
messages and responding to them), it seems unlikely that
anyone would take the effort.

And even if they did, the results would hardly be noticed.

I really do appreciate your reading my proposed solution
and giving feedback. As we move forward, however, I suggest
that we can probably make more progress if you attempt to
engage me and the remainder of the working group in a dialog
about how we can improve the solution, rather than airing a
laundry list of complaints.

/a

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 31 Oct 2002 11:35:47 -0000

> 3GPP has once rejected the one-bit RESET, because it used a 
> reserved bit that could interfere with future releases. If 
> IETF could reserve bit 4 for RESET this should not be a 
> problem anymore. Then we would have a quick solution that is 
> still nicer than reducing state memory size to 0.
> 
> With the other solution we could live with the lone RESET 
> signal for now and define more later or define a reasonable 
> set of errors (this would be better).

Hi,

In the interests of progressing this topic, what I believe
would be really useful for the working group is a list of
issues that are not handled well by the current SigComp
solution. Once these issues have been identified we can
make a decision on whether they are worth addressing by
standardising new recovery mechanisms.

I've made an attempt at starting this list below. The
following three scenarios are currently handled in SigComp
just by wiping the entire compartment; however, with a
more detailed list of error conditions it might be possible
for an endpoint to recover more quickly:

1.) If one state item is damaged then the compressor can
    avoid referencing it without needing to wipe the entire
    compartment.

2.) If a state item cannot be accessed due to not sending
    enough bytes of state ID, the compressor can send a
    longer state ID in future messages.

3.) The RESET signal indicates that the previously saved
    state has been lost, but that the original state
    memory is still available. This allows a compressor
    to upload state such as the user-specific dictionary
    with more confidence that it will be accepted.

I'd be grateful for suggestions on further issues that
could be added to the above list.

Regards,

Richard