Subject: [rohc] SigComp recovery I-D

From: [email-masked]
Date: Tue, 22 Oct 2002 13:33:06 -0500

Hello,

I have submitted an I-D on a recovery mechanism for SigComp.
Before it is announced by the I-D Editor, you can find it at:
http://people.nokia.net/vijayd/draft-liu-sigcomp-recovery-00.txt
Below is the abstract from the I-D.

Your comments are welcome.

BR,
Zhigang

-----------------------------------------
Abstract

   This document defines a recovery mechanism for signaling compression
   (SigComp).  It allows a decompressor to signal to its peer compressor
   in case it has lost synchronization with the compressor. The
   compressor can thereafter take appropriate actions. The signal can be
   carried using state announcement mechanism or reserved bits in the
   requested feedback data as defined in SigComp.
-----------------------------------------
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 23 Oct 2002 10:05:02 +0200

Zhigang,

This makes me confused. Without looking at all the details, this drafts seems to be addressing the same problem as has already been identified by the Adam Roach draft, draft-roach-sigcomp-nack-00.txt. Can you please clarify the purpose of this draft, compared to the Roach draft?

Thanx,
/L-E

 --------------------------------------------
 Abstract (draft-liu-sigcomp-recovery-00.txt)
 
    This document defines a recovery mechanism for signaling
    compression (SigComp).  It allows a decompressor to signal
    to its peer compressor in case it has lost synchronization
    with the compressor. The compressor can thereafter take
    appropriate actions. The signal can be carried using state
    announcement mechanism or reserved bits in the requested
    feedback data as defined in SigComp.

 --------------------------------------------
 Abstract (draft-roach-sigcomp-nack-00.txt)

    This document describes a mechanism that allows Signalling
    Compression (SigComp) implementations to report precise
    error information upon receipt of a message which cannot
    be decompressed. This negative feedback can be used by the
    recipient to make fine-grained adjustments to the
    compressed message before retransmitting it, allowing for
    rapid and efficient recovery from error situations.

---

From: [email-masked]
Date: Wed, 23 Oct 2002 22:12:17 -0500

Lars-Erik,

Actually, my I-D addresses the same issue I raised back in April:
"sigcomp issue zliu-3: cannot recovery from decompression failure". 
Please find details at:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00356.html

Below is what happened since then:

- Since other sigcomp authors thought zliu-3 was an implementation issue,
it was not addressed in the SigComp spec.
- The issue was taken up in 3GPP and Nokia made contribution regarding it.
- I have hoped that the issue would be closed there. However, Nokia's 
contribution met objections. In particular, Dynamicsoft proposed recently 
to have the issue resolved in IETF, instead of 3GPP.

So, we are back to where we were, after this big circle ...

Anyway, I was asked to write the draft for this 6-month old issue. The
current view of 3GPP, as far as I understand, is that they need a solution
by end of this year, preferably in November. That is to meet Rel5.

Hope this clarifies the situation.

BR,
Zhigang

> -----Original Message-----
> From: ext Lars-Erik Jonsson (EAB)
> [mailto:[email-masked]]
> Sent: October 23, 2002 3:05 AM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked]
> Subject: RE: [rohc] SigComp recovery I-D
> 
> 
> Zhigang,
> 
> This makes me confused. Without looking at all the details, 
> this drafts seems to be addressing the same problem as has 
> already been identified by the Adam Roach draft, 
> draft-roach-sigcomp-nack-00.txt. Can you please clarify the 
> purpose of this draft, compared to the Roach draft?
> 
> Thanx,
> /L-E
> 
>

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 24 Oct 2002 11:54:05 +0200

Zhigang and others,

> - Since other sigcomp authors thought zliu-3 was an 
> implementation issue, it was not addressed in the SigComp spec.

OK, my conclusion was that we had agreed this was an implementation
issue. The last message I can find regarding this is an answer from
Richard, dated April 25, where he presented the same resolution as
in yesterday's mail. That response was never questioned, and zliu-3
was therefore not even included in the list of unresolved issues.
 
Anyway, back to my question. Has not the Roach draft already
addressed this issue, or are we talking about two issues?
I interpret Richards answer from yesterday as if this is the
same issue, which does not necessarily call for additional
standardization, although it might potentially provide some
benefits if we do this. 

So, first I would like to understand whether we have two drafts
addressing the same problem, or if we have two problems to look
at?

Secondly, assuming this is one single issue, we will have to
see some arguments why this is worth the effort to standardize,
and especially why it would be "needed" (as has been claimed).

Rgds,
/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 24 Oct 2002 12:32:51 +0100

Hi,

I believe that both drafts address a single issue - how to recover
from the case that states are lost at an endpoint (due to
decompression failure or otherwise).

From my perspective I'd like to understand what features folks believe
are missing from the current SigComp solution and thus will require
additional standardisation. The detailed list of error conditions in
Adam's draft may be useful for debugging, and possibly for recovering
from state loss more quickly than just resetting the compartment. Are
there any other features not available as an implementation decision
within "ordinary" SigComp?

Regards,

Richard

> From: Lars-Erik Jonsson (EAB) 
> Sent: Thursday, October 24, 2002 10:54 AM
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 24 Oct 2002 10:26:58 -0500

> addressing the same problem

Yes, the zliu-3 which we probably should have paid more attention to.

> and especially why it would be "needed" (as has been claimed).

I think we are just doing that. Please read my draft and other emails.

Zhigang

---

From: [email-masked]
Date: Thu, 24 Oct 2002 10:47:09 -0500

Carsten and Lars-Erik,

Could we have a time slot for this issue in the Atlanta meeting?

BR,
Zhigang

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Oct 2002 15:42:39 -0500

> and especially why it would be "needed" (as has been claimed).

Perhaps "needed" is a bit too strong of a word.

"Useful" is what I'm aiming for. At its core, SigComp is
an attempt to limit the number of bytes sent over the air.
The addition of a NACK mechanism demonstratably aids that
attempt.

Left to the application layer, we need to wait for an
application timeout (usually involving several retransmissions)
and manual compartment reset before a failure can recover.
Even then, you can really only perform a complete reset of
the compartment, which would require sending a full set of
bytecodes with the next message. That can be bulky.

A NACK-type mechanism provides two distinct advantages
over leaving it to the application:

1. If you can surgically remove the offending state from the
   compartment without reseting the whole thing, there is
   a very high chance that the subsequent message will
   significantly smaller than a full reset.

2. By immediately signalling loss of state, recovery can
   occur almost instantly, and with only one retransmission,
   instead of relying on several applicaton-level
   retransmissions and timeouts.

The net effect: a NACK mechanism will typically result in
fewer messages and smaller messages. In other words, fewer
bytes sent across the air. Isn't that what we're all trying
to accomplish?

/a

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 25 Oct 2002 08:50:43 +0200

Zhigang,

That sound reasonable, we will have to spend some time on SigComp
issues. Still, the best if of course if that would only be used to
recapitulate what has already been resolved on the mail list. We
have now got discussions on this issue, and hopefully these will
continue so that we can figure out and agree on how to proceed.

Cheers,
/Lars-Erik

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 24 oktober 2002 17:47
> To: [email-masked]; [email-masked]
> Cc: [email-masked]