Subject: RE: [rohc] RE: SigComp Recovery - long

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 1 Nov 2002 12:40:18 +0100

Thanks Richard for trying to progress this discussion. We still
need to collect more concrete material to motivate doing work
on this, since we should not and can not create new work items
without convincing justifications.

Since we are here talking about recovery mechanisms for error
conditions, an obvious question is what would cause such error
conditions, and the next question is of course how realistic it
is to expect these to happen "often enough" to really justify
additional recovery mechanisms.

So far, I have not heard any principal objections to adding
some new explicit recovery mechanisms, but we still need to
justify the work. Some numbers would thus be good to have, at
least to get something to debate. New mechanisms must make a
difference under realistic circumstances, otherwise we have
better things to do.

Cheers,
/L-E

> 
> In the interests of progressing this topic, what I believe
> would be really useful for the working group is a list of
> issues that are not handled well by the current SigComp
> solution. Once these issues have been identified we can
> make a decision on whether they are worth addressing by
> standardising new recovery mechanisms.
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Mon, 4 Nov 2002 16:05:35 -0600

Richard,

I agree with your approach below. And we do need to make 
progress, hopefully fast enough to catch Release 5 in 3GPP.

As to the list itself, I don't have anything to add. In my view,
the most important issue is the RESET signal. I may be 
"lack of imagination" here. But I remember we did think about
many potential issues back in March/April. I wouldn't be surprised
if the list is short.

Again, time is critical. We need to move forward.

BR,
Zhigang

> -----Original Message-----
> From: ext Price, Richard [mailto:[email-masked]]
> Sent: October 31, 2002 5:36 AM
> To: Sugar Robert (NET/Budapest); 'Adam Roach'; Liu Zhigang.C
> (NRC/Dallas); 'Lars-Erik Jonsson (EAB)'; [email-masked]
> Subject: RE: [rohc] RE: SigComp Recovery - long
> 
> 
> > 3GPP has once rejected the one-bit RESET, because it used a 
> > reserved bit that could interfere with future releases. If 
> > IETF could reserve bit 4 for RESET this should not be a 
> > problem anymore. Then we would have a quick solution that is 
> > still nicer than reducing state memory size to 0.
> > 
> > With the other solution we could live with the lone RESET 
> > signal for now and define more later or define a reasonable 
> > set of errors (this would be better).
> 
> Hi,
> 
> I've made an attempt at starting this list below. The
> following three scenarios are currently handled in SigComp
> just by wiping the entire compartment; however, with a
> more detailed list of error conditions it might be possible
> for an endpoint to recover more quickly:
> 
> 1.) If one state item is damaged then the compressor can
>     avoid referencing it without needing to wipe the entire
>     compartment.
> 
> 2.) If a state item cannot be accessed due to not sending
>     enough bytes of state ID, the compressor can send a
>     longer state ID in future messages.
> 
> 3.) The RESET signal indicates that the previously saved
>     state has been lost, but that the original state
>     memory is still available. This allows a compressor
>     to upload state such as the user-specific dictionary
>     with more confidence that it will be accepted.
> 
> I'd be grateful for suggestions on further issues that
> could be added to the above list.
> 
> Regards,
> 
> Richard
>