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

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 20 Mar 2006 10:23:03 -0000

Hi Cristian, Pekka,

I've got a couple of points here:

Re: "returned feedback item" in a NACK message.

I think the field is there so that the message has the same format as an
ordinary SigComp message.  I wouldn't expect it to be filled in.
Pekka's examples do show a way it could theoretically be filled in,
however what would that actually mean?

Returned feedback says 'I decompressed this message correctly'
NACK says 'I had problem X when decompressing this message' (where X is
the reason code)

Putting the two in the same message is just confusing - which one should
the receiving compressor believe?  Presumably the NACK, in which case,
why send the feedback in the first place?

I think, if my reasoning above is correct, it may have made more sense
for the format of the NACK message (section 3.1) to have T=0 and not
show the returned feedback item.

What do you think?  Could this be something for the implementer's guide?
(There's not currently a NACK implementer's guide, but the SigComp
implementer's guide covers RFC 3321 and 3485 too so it could also cover
4077?)

Re: "state creation request is unsuccessful"

> 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 ?

Unsuccessful state creation means that a given piece of state is not
created.  If there are multiple requests for state creation in a
message, one may fail while the others succeed.  The decompression has
not failed so a NACK should not be returned.

INTERNAL_ERROR is defined for circumstances where "The UDVM encountered
an unexpected condition that prevented it from decompressing the
message."  
State processing does not take place within the running of the UDVM.
Receipt of this error (or at least repeated receipt) would imply to me
that the remote UDVM has a bug in one of the instructions my compressor
is using.

Therefore IMHO the answer is 1. nothing is reported.

Best regards,

Abbie

> -----Original Message-----
> From: Cristian CONSTANTIN [mailto:[email-masked]] 
> Sent: Wednesday, March 15, 2006 12:01 PM
> To: Pekka Pessi
> Cc: [email-masked]
> Subject: Re: [rohc] "returned feedback item" in NACK
> 
> On Wed, Mar 15, 2006 at 12:12:58AM +0200, Pekka Pessi wrote:
> > Cristian CONSTANTIN <[email-masked]> writes:
> > >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.
> > 
> > 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.
> 
> 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
> -- 
>  _          | 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: Cristian CONSTANTIN <[email-masked]>
Date: Mon, 20 Mar 2006 13:28:33 +0100

> implementer's guide covers RFC 3321 and 3485 too so it could also cover

cristian: well I guess we should wait for the NACK std. author's oppinion about
that.

another point here is that since code_len could have a non fixed offset
within the message header the decision (NACK/non-NACK) could be
tricky...

> Therefore IMHO the answer is 1. nothing is reported.

cristian: o.k. this was also my understanding. 

bye now!
cristian

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 Mar 2006 10:26:33 -0600

>cristian: well I guess we should wait for the NACK std. author's oppinion about

It wasn't really my idea; if I recall correctly, it was Richard Price 
who wanted the returned feedback portion to be available for returned 
feedback. In fact, in early versions of the NACK draft, the NACK details 
were in the returned feedback portion of the message, which make 
returned feedback in a NACK message impossible.

I think the use-case that Richard described was something along the 
lines of:

   A              B
   |--- MSG 1 --->|
   |--- MSG 2 --->|
   |<--- NACK ----|

In this case, MSG 1 decompresses successfully and creates a returned 
feedback object. MSG 2 fails to decompress and triggers a NACK. I think 
it would be legal (and potentially even useful) for this NACK message to 
contain the requested feedback that was created by MSG 1.

/a