Subject: [rohc] SigComp: proposal for a NACK mechanism

From: Adam Roach <[email-masked]>
Date: Tue, 1 Oct 2002 18:19:09 -0500

After a small amount of operational experience with SigComp
in simulated deployments, we have come to realize that
recovery from situations in which the view of stored state
differs between nodes is cumbersome, at best, with the
currently available mechanisms.

I have put together a draft on a mechanism to address this
situation: a negative acknowledgement mechanism for SigComp.

It has been submitted to the internet-drafts editor. Until it
appears in the repository, you may retrieve a copy from:

http://pages.sbcglobal.net/roaches/ietf/draft-roach-sigcomp-nack-00.txt

Also, an HTML version is available at:

http://pages.sbcglobal.net/roaches/ietf/draft-roach-sigcomp-nack-00.html

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

---

From: [email-masked]
Date: Thu, 3 Oct 2002 14:41:02 +0100

Adam,

I am just trying to get a basic understanding of your proposal, so here's a
question that I think I know the answer to, but I want to check:

Will the NACK message be 'piggy-backed' on top of another compressed SIP
message or is the NACK sent separately?

Oh- and am I right in saying that for the error 'STATE NOT FOUND' the NACK
can be as big as 44 bytes?

Cheers,

Duncan Mills

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: 02 October 2002 00:19
To: [email-masked]'
Subject: [rohc] SigComp: proposal for a NACK mechanism

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 3 Oct 2002 10:08:14 -0500

> From: [email-masked]
>

It is sent separately. Piggybacking suffers from the relic
that you must have traffic in the opposite direction before
recovery is possible. In many cases, this traffic will
be sparse; in others (pure client/server setups), it
will never actually occur.

> can be as big as 44 bytes?

In a degenerate case, yes. It's probably more realistic to
assume that state IDs will be on the order of 12 bytes
as an upper bound, which would make the messages 36 bytes
long.

/a

/a

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 10 Oct 2002 15:54:27 +0100

Hi,

I've attached some comments on the proposed NACK mechanism
for SigComp.

Regards,

Richard

-----------------------------------------------------------

Page 3: "this approach suffers from the unfortunate behavior
         that it requires a compressed application-level
         message in the reverse direction before recovery can
         occur"

In fact the SigComp draft itself does not prevent a compressor
from sending standalone SigComp messages. The decision is made
by the application running over SigComp - if the receiving
endpoint requests the compartment identifier for a standalone
message then it's an application decision whether to provide
one or not. Obviously some form of lower-layer security is
useful in this case so that the application is confident that
the standalone message has not been forged.

The decision on whether to accept a standalone message may
also depend on what the message is trying to achieve. If the
message requests the creation of new state, or offers
additional processing or memory resources, then the
application will need to be certain that it can correctly
identify the compartment to which the message belongs (since
a malicious message of this type can easily cause decompression
failures to occur). However, if the message only NACKs a
state item then the damage it can do is less severe (it can
lower the overall compression ratio by preventing perfectly
good state from being accessed, but it can't cause messages
to be incorrectly decompressed).

Page 4: "For a connectionless transport, such as UDP, the NACK
         message is sent back to the originator of the failed
         message at the port and IP address from which the
         message was sent. Note that this may or may not be
         the same port to which the appliation would typically
         receive messages."

Ideally we'd avoid generating messages on ports that the
application does not itself use, as we're trying to keep
SigComp as shim-like as possible (so to the transport layer
SigComp behaves just like the original application). However
I can't think of a better way to identify the recipient of the
NACK, so I guess that's life.

Page 8: SigComp NACK Message Format

The proposed NACK message format overwrites the "returned
feedback item" field which is used for ordinary (positive)
acknowledgements. In particular this means that ordinary
ACKs can only be sent piggybacked, even when there is
enough lower-layer security present to allow them to be
sent standalone. Why not instead put the NACK part of the
header in the "remaining SigComp message"? Any data contained
in this part of the message is discarded by a vanilla SigComp
implementation when code_len = 0, so it won't interfere
with an implementation that doesn't understand NACKs.

Page 11: "HUFFMAN_INVALID_PARAMETER"

This shouldn't cause a decompression failure to occur: if the
first "number of bits" parameter to an INPUT-HUFFMAN opcode is
zero then the UDVM should obtain 0 bits from the compressed
message and interpret them as an integer from 0 to 2^0 - 1
(i.e. it just returns the integer 0). Something to clarify
in AUTH48?

Here are some more reason codes that might come in handy:

ID_NOT_UNIQUE

A partial state identifier that was used to access state
matched more than one state item.

ID_TOO_SHORT

A unique state item was matched but fewer bytes of state ID
were sent than required by the minimum_access_length.

INVALID_OPERAND

An operand for an instruction could not be resolved to an
integer value (e.g. a literal or reference operand beginning
with 11111111).

MULTILOAD_OVERWRITTEN

A MULTILOAD instruction attempted to overwrite itself.

STATE_TOO_SHORT

A STATE-ACCESS instruction has attempted to copy more bytes
from a state item than the state item actually contains.

The first reason code in particular might be useful for
on-the-fly correction of errors: it indicates that a larger
partial state identifier must be sent in order to uniquely
reference an item of state.

> Sent: Wednesday, October 02, 2002 12:19 AM
> To: [email-masked]'

---

From: Adam Roach <[email-masked]>
Date: Fri, 11 Oct 2002 13:02:43 -0500

Thanks for the comments! Some replies inline.

> From: Price, Richard [mailto:[email-masked]]
>

Okay, so you're saying you think the mechanism is worthwhile, but
that the text is not factually accurate, right? I'll adjust it...

> NACK, so I guess that's life.

Yeah. For most UDP protocols, the response is sent back to the
originating IP/Port anyway. The only exception I know about is
SIP -- but since the application-level signalling needs to be
decoded to figure out where the sender is listening, we can't
"do the right thing" if we can't decode the message.

In practice, I see an increasing number of SIP implementations
sending from the same port they're listening on so as to make
firewall traversal easier.

> with an implementation that doesn't understand NACKs.

Are you saying you see a need for a combined ACK/NACK packet,
or just that the current format makes it difficult to differentiate
a NACK from a standalone ACK?

In either case, I have no objection to moving the NACK content to
the end of the packet; I don't think any additional complexity
arises from that...

> (i.e. it just returns the integer 0). Something to clarify

I don't think any clarification is necessary. My confusion
stemmed from a change in the draft that I didn't catch.

Sigcomp-05 said, "If bits_1 = 0 or (bits_1 + ... +
bits_n) > 16 then decompression failure occurs."  In 
sigcomp-07, it's been modified simply to, "Decompression
failure occurs if (bits_1 + ... + bits_n) > 16."

The additional failure codes are very helpful. Thanks!

/a

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 14 Oct 2002 11:26:30 +0100

> Thanks for the comments! Some replies inline.

You're welcome! I've attached a handful of minor clarifications
inline.

Regards,

Richard

> that the text is not factually accurate, right? I'll adjust it...

Precisely! The text currently states that basic SigComp doesn't
support standalone acknowledgements, whereas they may in fact be
allowed if sufficient security is provided by the application.

What's missing from basic SigComp however is the ability to send
NACKs as well as ordinary positive acknowledgements. I don't know
how useful NACKs will prove to be - we'll need more deployment
experience of SigComp to find out - but it's great to have the
mechanisms available to solve any problems that may arise.

> firewall traversal easier.

As an aside, the above issue is the reason I gave up on trying to
add NACK codes to basic SigComp. However, since you have far more
experience of actually deploying SIP that I do, if you say that
just sending the NACK messages back to the same port is ok then
it's fine by me :-)

> a NACK from a standalone ACK?

The second one. I can't see a need for a combined ACK/NACK packet,
but it would be useful to allow both standalone ACKs and standalone
NACKs to be sent by the same implementation. The current format does
not differentiate between the two types of acknowledgement so it
would be impossible to tell which one is intended unless one of the
types were banned.