Subject: RE: [rohc] SigComp Implementer's guide - it's that time again

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 1 Mar 2006 11:54:11 -0000

Hi John, all,

Thanks you for your responses on these issues.  They raise more
interesting questions :-)

In my original email, I had missed the statement "Note that there is no
need to transmit any requested feedback item more than once." so it was
my mistake and I wasn't intending to contradict SigComp.

However, this does raise the question of why you would want to send
feedback only once.  Presumably to save bandwidth but whether this is an
issue or not depends on the size of the feedback requested.

What happens if you sent the feedback on a 200OK to an invite which then
subsequently got retransmitted (because the ACK was not received)?
Surely in that case you would want to re-send the feedback because there
is a high likelihood that the feedback you previously sent has not been
received?

The statements you quoted below state only that the feedback SHOULD be
returned.  The note itself does not contain any 'standards language'.
Is there actually a case for clarifying this in the implementer's guide
that feedback should be returned multiple times?

(In either case an implementation has to deal with a remote
implementation that doesn't do so, but it's a question of what the
expected behaviour should be.)

What do you think?

Best regards,

Abbie
> 
> I said:
> 
> > So the 
> > scenarios covered by your new section 9.2 simply do not 
> > apply, if you stick to the SIGCOMP RFC. 
> 
> Perhaps I should have said that the scenarios only apply with reduced
> scope - to the case when an incoming message with requested 
> feedback is
> followed by another incoming message with 
> requested_feedback_location ==
> 0 or Q == 0, without an outgoing message have been sent in between.
> 
> John
> 
> > -----Original Message-----
> > From: John Barber [mailto:[email-masked]] 
> > Sent: 28 February 2006 14:35
> > To: Surtees, Abigail; [email-masked]
> > Subject: RE: [rohc] SigComp Implementer's guide - it's that 
> time again
> > 
> > Hi Abbie,
> > 
> > Sorry for the lateness of this reply.
> > 
> > Re: Updating feedback requests:
> > 
> > In your previous email, you wrote: "I assume that when an 
> > endpoint receives a valid message, it updates the feedback 
> > data for that compartment.  The endpoint should then set this 
> > feedback on every message sent within the compartment until 
> > it receives another valid message that updates the feedback."
> > 
> > This is also the assumption behind the wording of your 
> > proposed new section 9.2 below. However, this is contrary to 
> > what is specified in SIGCOMP Section 5:
> > 
> > *************
> >     Additionally, if the state handler passes some requested 
> > feedback to
> >     the compressor, then it SHOULD be returned in the next SigComp
> >     message generated by the compressor (unless the state 
> > handler passes
> >     some newer requested feedback before the older feedback has been
> >     sent, in which case the older feedback is deleted). 
> >     If present, the requested feedback item SHOULD be copied 
> > unmodified
> >     into the returned_feedback_item field provided in the SigComp
> >     message.  Note that there is no need to transmit any requested
> >     feedback item more than once.
> > *************
> > 
> > This is saying that any requested feedback should be sent on 
> > the *next* message generated by the compressor *only*. So the 
> > scenarios covered by your new section 9.2 simply do not 
> > apply, if you stick to the SIGCOMP RFC.
> > 
> > So, my question is, is it the case that the SIGCOMP spec is 
> > not viable in this respect and needs to be corrected, or has 
> > one of us made a mistake? If you are intentionally 
> > contradicting the SIGCOMP spec then I think this needs to be 
> > made clearer, e.g. by an explicit reference to SIGCOMP 
> > Section 5 and a statement that these provisions of SIGCOMP 
> > are to be disregarded.
> > 
> > Best regards, John
> > 

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

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 1 Mar 2006 15:05:18 +0100

> is a high likelihood that the feedback you previously sent has not been

cristian: so, you are sugesting here that the sigcomp stack should
realize a 200OK is _retransmitted_ by the sip stack; so your sigcomp
stack has to be able to (re)parse a sip message and interpret its
meaning or equivalently you'll have to signal somehow: careful now here
it comes a 200OK, right? would that not be overkill for sigcomp and actually for
your whole implementation?

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