Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0

From: "Price, Richard" <[email-masked]>
Date: Fri, 7 Feb 2003 09:58:55 -0000

> Hi,
> 
> (This is not specified on RFC 3320, so I want to double check.)
> 
> If a message carries state creation request but the receiving 
> endpoint has SMS = 0, I understand that the message can still be
> accepted but the state creation request will be rejected.

Hi Zhigang,

That's right - state creation requests can be rejected due to lack
of memory, even if the decompressed message is accepted.

> Now, what about the requested feedback carried in the message?
> Will it be returned?

The requested feedback can still be returned even if SMS = 0.

> If yes, that means the sender must not rely on feedback to determine
> if the state has been successfully created. Then, is the answer no?

The sender can still rely on the feedback to determine if the state
has been successfully created, but only if it takes into account the
returned SigComp parameters as well. In particular it needs to check
that the receiver has advertised SMS > 0.

SigComp-Extended has the following to say on the subject:

   Note: There is a possibility that state(S) is discarded due to lack
   of state memory even though the announcement information is
   successfully forwarded.  This possibility must be taken into account
   (otherwise a decompression failure may occur); this can be done by
   using the SigComp parameter state_memory_size which is announced by
   the SigComp feedback mechanism.  The endpoint can use this parameter
   to infer if a state creation request has failed due to lack of
   memory.

Hope this helps!

Regards,

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

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Fri, 7 Feb 2003 11:17:30 +0100

Hi,

This may help, but sending the returned parameters is not mandatory, moreover not recommended!

BR/Zacco

-----Original Message-----
From: Price, Richard [mailto:[email-masked]]
Sent: Friday, February 07, 2003 10:59 AM
To: [email-masked]'; [email-masked]
Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0

Hi Zhigang,

Hope this helps!

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 7 Feb 2003 10:51:26 -0000

Hi Zacco,

It's an implementation decision at the receiver whether to
announce that SMS > 0 or not. Note however that if the
receiver chooses not to do this, then the sender MUST
assume that SMS = 0 (in other words it has to assume that
the receiver can't save state).

Regards,

Richard

> From: Lajos Zaccomer (ETH) [mailto:[email-masked]]
> Sent: Friday, February 07, 2003 10:18 AM
> To: Price, Richard; [email-masked]'; [email-masked]
> Subject: RE: [rohc] SigComp state creation request, requested 
> feedback,
> a nd SMS = 0
> 
> 
> Hi,
>

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 7 Feb 2003 12:32:54 -0000

> Hi,
> 
> I am aware of this, but I think it is worth to indicate there 
> may be potential problems or low compression efficiency 
> issues because of this. Think of what happens if B does not 
> send the returned parameters: A has to send the bytecode in 
> every message. In such a situation B proves to perform better 
> than than A, unless A is brave enough not to send the bytecode again.

Hi Zacco,

It's worth pointing out that getting a good compression ratio
is the responsibility of both the sender and the receiver. Thus,
if the compression ratio is worse in the direction A -> B than in
the direction B -> A, it's wrong to claim that B is performing
better than A. It might be B's fault that the compression ratio
is low.

> Anyway, the RFC does not mandate that "it has to assume that 
> the receiver can't save state." (As far as I can remember, it 
> is not even recommended.)

In fact, from Section 5 of RFC 3320:

   "The compressor MUST ensure that the message can be decompressed
   using the resources available at the remote endpoint."

If the compressor assumes that the receiver can save state without
first checking that SMS > 0, then it's broken!

> It may be logical, but in situations when every byte spared
> is a success, the temptation is great to make "reckless"
> implementations that do not care of such things. Assumptions
> amongst "friend" softwares work well, which may pave the way
> before these, handicapping others.

I agree completely with the above - the temptation is great to
cut corners just to save a few bytes. The result is an
implementation that only interoperates with "friendly" software,
which is a Bad Thing!

We took care to specifically ban this kind of behaviour in
RFC 3320.

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 7 Feb 2003 13:24:57 -0000

Hi Val,

Basic SigComp (RFC 3320) doesn't have the ability to notify the remote
endpoint when decompression failure has occurred. The reason for this is
simply that if a SigComp message fails to decompress, how can we work
out which remote endpoint sent it? We can't successfully decompress the
"From:" header, so we don't know where to send the feedback.

In some cases it might be possible to work around this problem by
using the IP address and port - a proposal to do this can be found in:

http://www.ietf.org/internet-drafts/draft-roach-sigcomp-nack-00.txt

However, we haven't got around to standardising the above mechanism
just yet...

Regards,

Richard

> From: Valerie Kenneally [mailto:[email-masked]]
> Sent: Friday, February 07, 2003 11:29 AM
> To: [email-masked]
> Hi all,
> 	I am trying to understand the feedback mechanism provided by SIGCOMP.  My
> question is based on what happens if a remote endpoint receives a message
> which it cannot decompress for whatever reason so we have a DECOMPRESSION
> FAILURE.
> 
> Can the remote end-point notify the sending end-point that decompression has
> failed.  The reason I ask this is that the RFC states that feedback is
> piggybacked onto a Sigcomp message.
> 
> I don't know if I am completely misunderstanding the format of a Sigcomp
> message but should it not always contain a compressed message.  If a
> DECOMPRESSION FAILURE occurs a follow-up message/response cannot be sent.
> So can a Sigcomp message be sent for the sole purpose of DECOMPRESSION
> FAILURE notification without being accompanied by a compressed message?
> 
> 
> Any help at all would be greatly appreciated
> Regards,
> Val