Subject: [rohc] "returned feedback item" in NACK

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 1 Mar 2006 19:25:38 +0100

hi!

pls. refer to: SigComp NACK (RFC 4077), Figure 1: SigComp NACK Message
Format.

I fail to understand when a "returned feedback item" can be present in
such a header, why and most important, how does it get there.
here are my assumptions:

1. all the nack errors are (possibly) trigerred by the sigcomp
processing done up to the delivery of the uncompressed packet to the
"local application" (figure 1: High-level..., rfc3320, interface btw.
decompressor disp. and local appl.); that is: processing of the sigcomp
header, un-escaping the message (tcp), udvm interp.
2. none of the following proc., i.e.: compartment matching, state
handling, feedback proc., etc trigger a NACK.

now, under these assumptions: 
1. since the udvm interpretation did not finished (sucesfully) I have no
idea if a feedback was requested in this bytecode.
2. since the compartment matching/mapping did not even take place and
neither did the state handling I do not know what's my compartment or
the peer compartment. so I cannot tell whether a feedback is supposed to
be piggybacked on this message or not (due to a prev. feedback req.)

thanks in advance.
bye now!
cristian
-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Pekka Pessi <[email-masked]>
Date: Wed, 15 Mar 2006 00:12:58 +0200

>such a header, why and most important, how does it get there.

If the UDVM managed to start execute END-MESSAGE but then failed
(because it run out of cycles or memory needed to store the state
create request) it could stuff the returned feedback item to the
NACK message. Theoretically speaking. Also I guess INTERNAL_ERROR
covers quite a lot of ground.

--Pekka

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 15 Mar 2006 13:00:32 +0100

> covers quite a lot of ground.

cristian: hi! thanks for the hints; since you brought this into the discussion
here is another thing which is not clearly stated in the drafts/std. (at
least in my oppinion): should a failure of the state handler be reported 
back by using NACK (using for example an INTERNAL_ERROR) or not?... 
it is suggested though that following this NACK model, the compressor 
always should assume a state creation as sucessful; if it gets an error when
it tries to access it, then it should not use that state anylonger.

here's a paragraph from rfc3320 which I find ambigous in this respect:

6.2 Memory Management
...
3. If the state creation request contains a state_identifier that
      already exists then the state handler checks whether the requested
      state item is identical to the established state item and counts
      the state creation request as successful if this is the case.  If
      not then the state creation request is unsuccessful (although the
      probability that this will occur is vanishingly small).

what exactly does "the state creation request is unsuccessful" mean 
assuming a NACK behaviour of the decompressor:

1. nothing is reported back by the state handler. a NACK error will be 
reported when the state is being accessed.

2. an error is reported back using NACK. INTERNAL_ERROR ?

bye now!
cristian